* [PATCH 2/7] tty: serial: fsl_lpuart: free IDs allocated by IDA
From: Michael Walle @ 2020-02-20 17:43 UTC (permalink / raw)
To: linux-serial, devicetree, linux-kernel, linux-arm-kernel
Cc: Mark Rutland, Peng Fan, Greg Kroah-Hartman, Li Yang,
Michael Walle, Rob Herring, Yuan Yao, Vabhav Sharma, Jiri Slaby,
Shawn Guo
In-Reply-To: <20200220174334.23322-1-michael@walle.cc>
Since commit 3bc3206e1c0f ("serial: fsl_lpuart: Remove the alias node
dependence") the port line number can also be allocated by IDA, but in
case of an error the ID will no be removed again. More importantly, any
ID will be freed in remove(), even if it wasn't allocated but instead
fetched by of_alias_get_id(). If it was not allocated by IDA there will
be a warning:
WARN(1, "ida_free called for id=%d which is not allocated.\n", id);
Move the ID allocation more to the end of the probe() so that we still
can use plain return in the first error cases.
Fixes: 3bc3206e1c0f ("serial: fsl_lpuart: Remove the alias node dependence")
Signed-off-by: Michael Walle <michael@walle.cc>
---
drivers/tty/serial/fsl_lpuart.c | 39 ++++++++++++++++++++-------------
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 27fdc131c352..c31b8f3db6bf 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -264,6 +264,7 @@ struct lpuart_port {
int rx_dma_rng_buf_len;
unsigned int dma_tx_nents;
wait_queue_head_t dma_wait;
+ bool id_allocated;
};
struct lpuart_soc_data {
@@ -2422,19 +2423,6 @@ static int lpuart_probe(struct platform_device *pdev)
if (!sport)
return -ENOMEM;
- ret = of_alias_get_id(np, "serial");
- if (ret < 0) {
- ret = ida_simple_get(&fsl_lpuart_ida, 0, UART_NR, GFP_KERNEL);
- if (ret < 0) {
- dev_err(&pdev->dev, "port line is full, add device failed\n");
- return ret;
- }
- }
- if (ret >= ARRAY_SIZE(lpuart_ports)) {
- dev_err(&pdev->dev, "serial%d out of range\n", ret);
- return -EINVAL;
- }
- sport->port.line = ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sport->port.membase = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(sport->port.membase))
@@ -2479,9 +2467,25 @@ static int lpuart_probe(struct platform_device *pdev)
}
}
+ ret = of_alias_get_id(np, "serial");
+ if (ret < 0) {
+ ret = ida_simple_get(&fsl_lpuart_ida, 0, UART_NR, GFP_KERNEL);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "port line is full, add device failed\n");
+ return ret;
+ }
+ sport->id_allocated = true;
+ }
+ if (ret >= ARRAY_SIZE(lpuart_ports)) {
+ dev_err(&pdev->dev, "serial%d out of range\n", ret);
+ ret = -EINVAL;
+ goto failed_out_of_range;
+ }
+ sport->port.line = ret;
+
ret = lpuart_enable_clks(sport);
if (ret)
- return ret;
+ goto failed_clock_enable;
sport->port.uartclk = lpuart_get_baud_clk_rate(sport);
lpuart_ports[sport->port.line] = sport;
@@ -2531,6 +2535,10 @@ static int lpuart_probe(struct platform_device *pdev)
failed_attach_port:
failed_irq_request:
lpuart_disable_clks(sport);
+failed_clock_enable:
+failed_out_of_range:
+ if (sport->id_allocated)
+ ida_simple_remove(&fsl_lpuart_ida, sport->port.line);
return ret;
}
@@ -2540,7 +2548,8 @@ static int lpuart_remove(struct platform_device *pdev)
uart_remove_one_port(&lpuart_reg, &sport->port);
- ida_simple_remove(&fsl_lpuart_ida, sport->port.line);
+ if (sport->id_allocated)
+ ida_simple_remove(&fsl_lpuart_ida, sport->port.line);
lpuart_disable_clks(sport);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/7] tty: serial: fsl_lpuart: handle EPROBE_DEFER for DMA
From: Michael Walle @ 2020-02-20 17:43 UTC (permalink / raw)
To: linux-serial, devicetree, linux-kernel, linux-arm-kernel
Cc: Mark Rutland, Peng Fan, Greg Kroah-Hartman, Li Yang,
Michael Walle, Rob Herring, Yuan Yao, Vabhav Sharma, Jiri Slaby,
Shawn Guo
In-Reply-To: <20200220174334.23322-1-michael@walle.cc>
The DMA channel might not be available at the first probe time. This is
esp. the case if the DMA controller has an IOMMU mapping.
Use the new dma_request_chan() API and handle EPROBE_DEFER errors. Also
reorder the code a bit, so that we don't prepare the whole UART just to
determine that the DMA channel is not ready yet and we have to undo all
the stuff. Try to map the DMA channels earlier.
Signed-off-by: Michael Walle <michael@walle.cc>
---
drivers/tty/serial/fsl_lpuart.c | 35 +++++++++++++++++++++++----------
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index c31b8f3db6bf..fd9f60d0817a 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -2416,6 +2416,7 @@ static int lpuart_probe(struct platform_device *pdev)
const struct lpuart_soc_data *sdata = of_id->data;
struct device_node *np = pdev->dev.of_node;
struct lpuart_port *sport;
+ struct dma_chan *dma_chan;
struct resource *res;
int ret;
@@ -2483,6 +2484,26 @@ static int lpuart_probe(struct platform_device *pdev)
}
sport->port.line = ret;
+ dma_chan = dma_request_chan(sport->port.dev, "tx");
+ if (PTR_ERR(dma_chan) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto failed_request_tx_dma;
+ } else if (IS_ERR(dma_chan))
+ dev_info(sport->port.dev, "DMA tx channel request failed, "
+ "operating without tx DMA\n");
+ else
+ sport->dma_tx_chan = dma_chan;
+
+ dma_chan = dma_request_chan(sport->port.dev, "rx");
+ if (PTR_ERR(dma_chan) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto failed_request_rx_dma;
+ } else if (IS_ERR(dma_chan))
+ dev_info(sport->port.dev, "DMA rx channel request failed, "
+ "operating without rx DMA\n");
+ else
+ sport->dma_rx_chan = dma_chan;
+
ret = lpuart_enable_clks(sport);
if (ret)
goto failed_clock_enable;
@@ -2520,22 +2541,16 @@ static int lpuart_probe(struct platform_device *pdev)
sport->port.rs485_config(&sport->port, &sport->port.rs485);
- sport->dma_tx_chan = dma_request_slave_channel(sport->port.dev, "tx");
- if (!sport->dma_tx_chan)
- dev_info(sport->port.dev, "DMA tx channel request failed, "
- "operating without tx DMA\n");
-
- sport->dma_rx_chan = dma_request_slave_channel(sport->port.dev, "rx");
- if (!sport->dma_rx_chan)
- dev_info(sport->port.dev, "DMA rx channel request failed, "
- "operating without rx DMA\n");
-
return 0;
failed_attach_port:
failed_irq_request:
lpuart_disable_clks(sport);
failed_clock_enable:
+ dma_release_channel(sport->dma_rx_chan);
+failed_request_rx_dma:
+ dma_release_channel(sport->dma_tx_chan);
+failed_request_tx_dma:
failed_out_of_range:
if (sport->id_allocated)
ida_simple_remove(&fsl_lpuart_ida, sport->port.line);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [meta-virtualization][PATCH] openvswitch: uprev from v2.12 to v2.13
From: Bruce Ashfield @ 2020-02-20 17:44 UTC (permalink / raw)
To: Mark Asselstine; +Cc: meta-virtualization
In-Reply-To: <1582160864-1989-1-git-send-email-mark.asselstine@windriver.com>
merged.
Bruce
In message: [meta-virtualization][PATCH] openvswitch: uprev from v2.12 to v2.13
on 19/02/2020 Mark Asselstine wrote:
> Another straightforward uprev with one fairly large change in the
> changelog. The Open Virtual Network component has now been moved to
> its own repo (https://github.com/ovn-org/ovn.git). If you were using
> this functionality a new recipe will need to be created.
>
> The ptest results are similar to after the v2.12 uprev
>
> ERROR: 2206 tests were run,
> 28 failed unexpectedly.
> 62 tests were skipped.
>
> The failed tests were in the following areas:
> checkpatch.at (5)
> ovs-ofctl.at (1)
> tunnel.at(1)
> tunnel-push-pop.at(3)
> tunnel-push-pop-ipv6.at(3)
> dpif-netdev.at (1)
> pmd.at(1)
> ofproto-dpif.at (7)
> bridge.at (2)
> ovsdb-idl.at(1)
> mcast-snooping.at(1)
> packet-type-aware.at(2)
>
> None of these affect core functionality or usecases and are similar to
> the results we see with v1.12. If specific usecases are affected by
> these failures we should address them on a need to fix basis.
>
> Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> ---
> ...on-make-remaining-scripts-use-usr-bin-env.patch | 373 ---------------------
> ...n-switch-remaining-scripts-to-use-python3.patch | 13 +-
> ...Define-WAIT_ANY-if-not-provided-by-system.patch | 29 --
> ...71d553b995d0bd527d3ab1e9fbaf5a2ae34de2f3.patch} | 0
> ...-idlc.in-fix-dict-change-during-iteration.patch | 45 ---
> recipes-networking/openvswitch/openvswitch_git.bb | 13 +-
> 6 files changed, 6 insertions(+), 467 deletions(-)
> delete mode 100644 recipes-networking/openvswitch/files/python-make-remaining-scripts-use-usr-bin-env.patch
> delete mode 100644 recipes-networking/openvswitch/openvswitch-git/0002-Define-WAIT_ANY-if-not-provided-by-system.patch
> rename recipes-networking/openvswitch/openvswitch-git/{openvswitch-add-ptest-6beb94976e2b3e0c51430b63214de14186d8db39.patch => openvswitch-add-ptest-71d553b995d0bd527d3ab1e9fbaf5a2ae34de2f3.patch} (100%)
> delete mode 100644 recipes-networking/openvswitch/openvswitch-git/ovsdb-idlc.in-fix-dict-change-during-iteration.patch
>
> diff --git a/recipes-networking/openvswitch/files/python-make-remaining-scripts-use-usr-bin-env.patch b/recipes-networking/openvswitch/files/python-make-remaining-scripts-use-usr-bin-env.patch
> deleted file mode 100644
> index 53e3103..0000000
> --- a/recipes-networking/openvswitch/files/python-make-remaining-scripts-use-usr-bin-env.patch
> +++ /dev/null
> @@ -1,373 +0,0 @@
> -From a348e0162343f7d46443eb1fd2bcf0698460a780 Mon Sep 17 00:00:00 2001
> -From: "Hongzhi.Song" <hongzhi.song@windriver.com>
> -Date: Wed, 23 Jan 2019 04:28:28 -0500
> -Subject: [PATCH] python: make remaining scripts use /usr/bin/env
> -
> -Unfortunately there is no concept of a host python vs. target python
> -to facilitate cross compilation. There is only one PYTHON variable and
> -this is used during building and in the header of python scripts after
> -installation. The best approach for cross compilation is to thus to
> -ensure python is in the path and avoid passing a path as part of
> -PYTHON. To make this function smoothly all installed scripts should
> -make use of /usr/bin/env to increase the chances of finding python.
> -
> -Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> -Signed-off-by: Hongzhi.Song <hongzhi.song@windriver.com>
> ----
> - build-aux/check-structs | 2 +-
> - build-aux/dpdkstrip.py | 2 +-
> - build-aux/extract-ofp-actions | 2 +-
> - build-aux/extract-ofp-errors | 2 +-
> - build-aux/extract-ofp-fields | 2 +-
> - build-aux/extract-ofp-msgs | 2 +-
> - build-aux/sodepends.py | 2 +-
> - build-aux/soexpand.py | 2 +-
> - build-aux/text2c | 2 +-
> - build-aux/xml2nroff | 2 +-
> - ovn/utilities/ovn-detrace.in | 2 +-
> - ovn/utilities/ovn-docker-overlay-driver.in | 2 +-
> - ovn/utilities/ovn-docker-underlay-driver.in | 2 +-
> - ovsdb/dot2pic | 2 +-
> - ovsdb/ovsdb-doc | 2 +-
> - ovsdb/ovsdb-dot.in | 2 +-
> - ovsdb/ovsdb-idlc.in | 2 +-
> - python/build/soutil.py | 2 +-
> - tests/flowgen.py | 2 +-
> - tests/ovsdb-monitor-sort.py | 2 +-
> - tests/uuidfilt.py | 2 +-
> - utilities/bugtool/ovs-bugtool.in | 2 +-
> - utilities/ovs-check-dead-ifs.in | 2 +-
> - utilities/ovs-dpctl-top.in | 2 +-
> - utilities/ovs-l3ping.in | 2 +-
> - utilities/ovs-parse-backtrace.in | 2 +-
> - utilities/ovs-pcap.in | 2 +-
> - utilities/ovs-tcpdump.in | 2 +-
> - utilities/ovs-tcpundump.in | 2 +-
> - utilities/ovs-test.in | 2 +-
> - utilities/ovs-vlan-test.in | 2 +-
> - vtep/ovs-vtep.in | 2 +-
> - 32 files changed, 32 insertions(+), 32 deletions(-)
> -
> -diff --git a/build-aux/check-structs b/build-aux/check-structs
> -index 37ffa06..eb44c91 100755
> ---- a/build-aux/check-structs
> -+++ b/build-aux/check-structs
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/python
> -+#! /usr/bin/env python3
> -
> - import os.path
> - import sys
> -diff --git a/build-aux/dpdkstrip.py b/build-aux/dpdkstrip.py
> -index 48c7f06..b8b8ba9 100755
> ---- a/build-aux/dpdkstrip.py
> -+++ b/build-aux/dpdkstrip.py
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/env python
> -+#! /usr/bin/env python3
> - # Copyright (c) 2017 Red Hat, Inc.
> - #
> - # Licensed under the Apache License, Version 2.0 (the "License");
> -diff --git a/build-aux/extract-ofp-actions b/build-aux/extract-ofp-actions
> -index 64de0f3..f6bca0b 100755
> ---- a/build-aux/extract-ofp-actions
> -+++ b/build-aux/extract-ofp-actions
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/python
> -+#! /usr/bin/env python3
> -
> - import getopt
> - import sys
> -diff --git a/build-aux/extract-ofp-errors b/build-aux/extract-ofp-errors
> -index 6f64efd..c410fd4 100755
> ---- a/build-aux/extract-ofp-errors
> -+++ b/build-aux/extract-ofp-errors
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/python
> -+#! /usr/bin/env python3
> -
> - import sys
> - import os.path
> -diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
> -index 3592594..2fc8317 100755
> ---- a/build-aux/extract-ofp-fields
> -+++ b/build-aux/extract-ofp-fields
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/python
> -+#! /usr/bin/env python3
> -
> - import getopt
> - import sys
> -diff --git a/build-aux/extract-ofp-msgs b/build-aux/extract-ofp-msgs
> -index a67e870..92c4bda 100755
> ---- a/build-aux/extract-ofp-msgs
> -+++ b/build-aux/extract-ofp-msgs
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/python
> -+#! /usr/bin/env python3
> -
> - import sys
> - import os.path
> -diff --git a/build-aux/sodepends.py b/build-aux/sodepends.py
> -index 90cfaa0..45812bc 100755
> ---- a/build-aux/sodepends.py
> -+++ b/build-aux/sodepends.py
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/env python
> -+#! /usr/bin/env python3
> -
> - # Copyright (c) 2008, 2011, 2017 Nicira, Inc.
> - #
> -diff --git a/build-aux/soexpand.py b/build-aux/soexpand.py
> -index 53ca640..00adcf4 100755
> ---- a/build-aux/soexpand.py
> -+++ b/build-aux/soexpand.py
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/env python
> -+#! /usr/bin/env python3
> -
> - # Copyright (c) 2008, 2017 Nicira, Inc.
> - #
> -diff --git a/build-aux/text2c b/build-aux/text2c
> -index cb1f256..ab7910e 100755
> ---- a/build-aux/text2c
> -+++ b/build-aux/text2c
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/python
> -+#! /usr/bin/env python3
> -
> - import re
> - import sys
> -diff --git a/build-aux/xml2nroff b/build-aux/xml2nroff
> -index bd4e879..db45c56 100755
> ---- a/build-aux/xml2nroff
> -+++ b/build-aux/xml2nroff
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/python
> -+#! /usr/bin/env python3
> -
> - # Copyright (c) 2010, 2011, 2012, 2013, 2014, 2015, 2016 Nicira, Inc.
> - #
> -diff --git a/ovn/utilities/ovn-detrace.in b/ovn/utilities/ovn-detrace.in
> -index c842adc..9e95183 100755
> ---- a/ovn/utilities/ovn-detrace.in
> -+++ b/ovn/utilities/ovn-detrace.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - #
> - # Copyright (c) 2017 eBay Inc.
> - #
> -diff --git a/ovn/utilities/ovn-docker-overlay-driver.in b/ovn/utilities/ovn-docker-overlay-driver.in
> -index 65edfcd..895426b 100755
> ---- a/ovn/utilities/ovn-docker-overlay-driver.in
> -+++ b/ovn/utilities/ovn-docker-overlay-driver.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - # Copyright (C) 2015 Nicira, Inc.
> - #
> - # Licensed under the Apache License, Version 2.0 (the "License");
> -diff --git a/ovn/utilities/ovn-docker-underlay-driver.in b/ovn/utilities/ovn-docker-underlay-driver.in
> -index d91ce9f..e0c8db6 100755
> ---- a/ovn/utilities/ovn-docker-underlay-driver.in
> -+++ b/ovn/utilities/ovn-docker-underlay-driver.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - # Copyright (C) 2015 Nicira, Inc.
> - #
> - # Licensed under the Apache License, Version 2.0 (the "License");
> -diff --git a/ovsdb/dot2pic b/ovsdb/dot2pic
> -index de67261..174e723 100755
> ---- a/ovsdb/dot2pic
> -+++ b/ovsdb/dot2pic
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/env python
> -+#! /usr/bin/env python3
> -
> - # Copyright (c) 2009, 2010, 2011, 2013, 2017 Nicira, Inc.
> - #
> -diff --git a/ovsdb/ovsdb-doc b/ovsdb/ovsdb-doc
> -index 406c293..d55c6e6 100755
> ---- a/ovsdb/ovsdb-doc
> -+++ b/ovsdb/ovsdb-doc
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/python
> -+#! /usr/bin/env python3
> -
> - # Copyright (c) 2010, 2011, 2012, 2013, 2014, 2015 Nicira, Inc.
> - #
> -diff --git a/ovsdb/ovsdb-dot.in b/ovsdb/ovsdb-dot.in
> -index 8eea617..38ba33a 100755
> ---- a/ovsdb/ovsdb-dot.in
> -+++ b/ovsdb/ovsdb-dot.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#! /usr/bin/env @PYTHON@
> -
> - from datetime import date
> - import ovs.db.error
> -diff --git a/ovsdb/ovsdb-idlc.in b/ovsdb/ovsdb-idlc.in
> -index 40fef39..84c63a6 100755
> ---- a/ovsdb/ovsdb-idlc.in
> -+++ b/ovsdb/ovsdb-idlc.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> -
> - from __future__ import print_function
> - import getopt
> -diff --git a/python/build/soutil.py b/python/build/soutil.py
> -index b8027af..8f52803 100755
> ---- a/python/build/soutil.py
> -+++ b/python/build/soutil.py
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/env python
> -+#! /usr/bin/env python3
> -
> - # Copyright (c) 2008, 2017 Nicira, Inc.
> - #
> -diff --git a/tests/flowgen.py b/tests/flowgen.py
> -index 976fe7a..7ef32d1 100755
> ---- a/tests/flowgen.py
> -+++ b/tests/flowgen.py
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/env python
> -+#! /usr/bin/env python3
> -
> - # Copyright (c) 2009, 2010, 2011, 2012, 2015, 2017 Nicira, Inc.
> - #
> -diff --git a/tests/ovsdb-monitor-sort.py b/tests/ovsdb-monitor-sort.py
> -index 7d368a7..ab4c38c 100755
> ---- a/tests/ovsdb-monitor-sort.py
> -+++ b/tests/ovsdb-monitor-sort.py
> -@@ -1,4 +1,4 @@
> --#! /usr/bin/env python
> -+#! /usr/bin/env python3
> -
> - # Breaks lines read from stdin into groups using blank lines as
> - # group separators, then sorts lines within the groups for
> -diff --git a/tests/uuidfilt.py b/tests/uuidfilt.py
> -index ea72812..f1a9aff 100755
> ---- a/tests/uuidfilt.py
> -+++ b/tests/uuidfilt.py
> -@@ -1,4 +1,4 @@
> --#!/usr/bin/env python
> -+#!/usr/bin/env python3
> -
> - import re
> - import sys
> -diff --git a/utilities/bugtool/ovs-bugtool.in b/utilities/bugtool/ovs-bugtool.in
> -index 288c34f..b5a6906 100755
> ---- a/utilities/bugtool/ovs-bugtool.in
> -+++ b/utilities/bugtool/ovs-bugtool.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#! /usr/bin/env @PYTHON@
> -
> - # This library is free software; you can redistribute it and/or
> - # modify it under the terms of version 2.1 of the GNU Lesser General Public
> -diff --git a/utilities/ovs-check-dead-ifs.in b/utilities/ovs-check-dead-ifs.in
> -index ac54f6c..13d86b3 100755
> ---- a/utilities/ovs-check-dead-ifs.in
> -+++ b/utilities/ovs-check-dead-ifs.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> -
> - import os
> - import re
> -diff --git a/utilities/ovs-dpctl-top.in b/utilities/ovs-dpctl-top.in
> -index 7f0f1f8..ece707a 100755
> ---- a/utilities/ovs-dpctl-top.in
> -+++ b/utilities/ovs-dpctl-top.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - #
> - # Copyright (c) 2013 Nicira, Inc.
> - #
> -diff --git a/utilities/ovs-l3ping.in b/utilities/ovs-l3ping.in
> -index 1b07972..9852699 100644
> ---- a/utilities/ovs-l3ping.in
> -+++ b/utilities/ovs-l3ping.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - #
> - # Licensed under the Apache License, Version 2.0 (the "License");
> - # you may not use this file except in compliance with the License.
> -diff --git a/utilities/ovs-parse-backtrace.in b/utilities/ovs-parse-backtrace.in
> -index 350cbd9..1960fb4 100755
> ---- a/utilities/ovs-parse-backtrace.in
> -+++ b/utilities/ovs-parse-backtrace.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - #
> - # Copyright (c) 2012 Nicira, Inc.
> - #
> -diff --git a/utilities/ovs-pcap.in b/utilities/ovs-pcap.in
> -index 7bebc07..b4e5ca8 100755
> ---- a/utilities/ovs-pcap.in
> -+++ b/utilities/ovs-pcap.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - #
> - # Copyright (c) 2010 Nicira, Inc.
> - #
> -diff --git a/utilities/ovs-tcpdump.in b/utilities/ovs-tcpdump.in
> -index 22f249f..ff2a51e 100755
> ---- a/utilities/ovs-tcpdump.in
> -+++ b/utilities/ovs-tcpdump.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - #
> - # Copyright (c) 2016 Red Hat, Inc.
> - #
> -diff --git a/utilities/ovs-tcpundump.in b/utilities/ovs-tcpundump.in
> -index c298700..0d8b8da 100755
> ---- a/utilities/ovs-tcpundump.in
> -+++ b/utilities/ovs-tcpundump.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - #
> - # Copyright (c) 2010 Nicira, Inc.
> - #
> -diff --git a/utilities/ovs-test.in b/utilities/ovs-test.in
> -index fb1f9ad..4dba169 100644
> ---- a/utilities/ovs-test.in
> -+++ b/utilities/ovs-test.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - #
> - # Licensed under the Apache License, Version 2.0 (the "License");
> - # you may not use this file except in compliance with the License.
> -diff --git a/utilities/ovs-vlan-test.in b/utilities/ovs-vlan-test.in
> -index e229498..5b70118 100755
> ---- a/utilities/ovs-vlan-test.in
> -+++ b/utilities/ovs-vlan-test.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - #
> - # Copyright (c) 2010 Nicira, Inc.
> - #
> -diff --git a/vtep/ovs-vtep.in b/vtep/ovs-vtep.in
> -index 3383870..42f98db 100755
> ---- a/vtep/ovs-vtep.in
> -+++ b/vtep/ovs-vtep.in
> -@@ -1,4 +1,4 @@
> --#! @PYTHON@
> -+#!/usr/bin/env @PYTHON@
> - # Copyright (C) 2013 Nicira, Inc. All Rights Reserved.
> - #
> - # Licensed under the Apache License, Version 2.0 (the "License");
> ---
> -2.8.1
> -
> diff --git a/recipes-networking/openvswitch/files/python-switch-remaining-scripts-to-use-python3.patch b/recipes-networking/openvswitch/files/python-switch-remaining-scripts-to-use-python3.patch
> index 64e0e3f..113bc91 100644
> --- a/recipes-networking/openvswitch/files/python-switch-remaining-scripts-to-use-python3.patch
> +++ b/recipes-networking/openvswitch/files/python-switch-remaining-scripts-to-use-python3.patch
> @@ -10,13 +10,12 @@ Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> ---
> ofproto/ipfix-gen-entities | 2 +-
> tests/test-l7.py | 2 +-
> - utilities/checkpatch.py | 2 +-
> utilities/ovs-dev.py | 2 +-
> utilities/ovs-pipegen.py | 2 +-
> xenserver/etc_xapi.d_plugins_openvswitch-cfg-update | 2 +-
> xenserver/opt_xensource_libexec_interface-reconfigure | 2 +-
> xenserver/usr_share_openvswitch_scripts_ovs-xapi-sync | 2 +-
> - 8 files changed, 8 insertions(+), 8 deletions(-)
> + 7 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/ofproto/ipfix-gen-entities b/ofproto/ipfix-gen-entities
> index 0be7199..d2cce42 100755
> @@ -38,16 +37,6 @@ index d7854a1..f09defb 100755
> # Copyright (c) 2015, 2016 Nicira, Inc.
> #
> # Licensed under the Apache License, Version 2.0 (the "License");
> -diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
> -index f929714..e17a1cf 100755
> ---- a/utilities/checkpatch.py
> -+++ b/utilities/checkpatch.py
> -@@ -1,4 +1,4 @@
> --#!/usr/bin/env python
> -+#!/usr/bin/env python3
> - # Copyright (c) 2016, 2017 Red Hat, Inc.
> - # Copyright (c) 2018 Nicira, Inc.
> - #
> diff --git a/utilities/ovs-dev.py b/utilities/ovs-dev.py
> index 9ce0f04..839e13e 100755
> --- a/utilities/ovs-dev.py
> diff --git a/recipes-networking/openvswitch/openvswitch-git/0002-Define-WAIT_ANY-if-not-provided-by-system.patch b/recipes-networking/openvswitch/openvswitch-git/0002-Define-WAIT_ANY-if-not-provided-by-system.patch
> deleted file mode 100644
> index f997bbf..0000000
> --- a/recipes-networking/openvswitch/openvswitch-git/0002-Define-WAIT_ANY-if-not-provided-by-system.patch
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -From 801023e72b31e7c49cbccedd76ade33a17fcbe45 Mon Sep 17 00:00:00 2001
> -From: Khem Raj <raj.khem@gmail.com>
> -Date: Mon, 20 Mar 2017 12:13:30 -0700
> -Subject: [PATCH] Define WAIT_ANY if not provided by system
> -
> -POSIX does not define it and uses -1 directly
> -some libc do not have this definitions
> -
> -Signed-off-by: Khem Raj <raj.khem@gmail.com>
> -
> ----
> - tests/test-ovn.c | 4 ++++
> - 1 file changed, 4 insertions(+)
> -
> -diff --git a/tests/test-ovn.c b/tests/test-ovn.c
> -index 84adf81..2bc6bdf 100644
> ---- a/tests/test-ovn.c
> -+++ b/tests/test-ovn.c
> -@@ -38,6 +38,10 @@
> - #include "simap.h"
> - #include "util.h"
> -
> -+#ifndef WAIT_ANY
> -+# define WAIT_ANY (-1) /* Any process. */
> -+#endif
> -+
> - /* --relops: Bitmap of the relational operators to test, in exhaustive test. */
> - static unsigned int test_relops;
> -
> diff --git a/recipes-networking/openvswitch/openvswitch-git/openvswitch-add-ptest-6beb94976e2b3e0c51430b63214de14186d8db39.patch b/recipes-networking/openvswitch/openvswitch-git/openvswitch-add-ptest-71d553b995d0bd527d3ab1e9fbaf5a2ae34de2f3.patch
> similarity index 100%
> rename from recipes-networking/openvswitch/openvswitch-git/openvswitch-add-ptest-6beb94976e2b3e0c51430b63214de14186d8db39.patch
> rename to recipes-networking/openvswitch/openvswitch-git/openvswitch-add-ptest-71d553b995d0bd527d3ab1e9fbaf5a2ae34de2f3.patch
> diff --git a/recipes-networking/openvswitch/openvswitch-git/ovsdb-idlc.in-fix-dict-change-during-iteration.patch b/recipes-networking/openvswitch/openvswitch-git/ovsdb-idlc.in-fix-dict-change-during-iteration.patch
> deleted file mode 100644
> index bf49ff6..0000000
> --- a/recipes-networking/openvswitch/openvswitch-git/ovsdb-idlc.in-fix-dict-change-during-iteration.patch
> +++ /dev/null
> @@ -1,45 +0,0 @@
> -From d84109f0b60096ce71cd0537b31b69a7f5ea8756 Mon Sep 17 00:00:00 2001
> -From: Flavio Leitner <fbl@sysclose.org>
> -Date: Sat, 14 Sep 2019 20:17:28 -0300
> -Subject: [PATCH] ovsdb-idlc.in: fix dict change during iteration.
> -
> -Commit d84109f0b600 from git://github.com/openvswitch/ovs.git
> -
> -Python3 complains if a dict key is changed during the
> -iteration.
> -
> -Use list() to create a copy of it.
> -
> -Traceback (most recent call last):
> - File "./ovsdb/ovsdb-idlc.in", line 1581, in <module>
> - func(*args[1:])
> - File "./ovsdb/ovsdb-idlc.in", line 185, in printCIDLHeader
> - replace_cplusplus_keyword(schema)
> - File "./ovsdb/ovsdb-idlc.in", line 179, in replace_cplusplus_keyword
> - for columnName in table.columns:
> -RuntimeError: dictionary keys changed during iteration
> -
> -Signed-off-by: Flavio Leitner <fbl@sysclose.org>
> -Signed-off-by: Ben Pfaff <blp@ovn.org>
> -[MA: Upstream-Status: Submitted]
> -Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> ----
> - ovsdb/ovsdb-idlc.in | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/ovsdb/ovsdb-idlc.in b/ovsdb/ovsdb-idlc.in
> -index 40fef39..22d0a4e 100755
> ---- a/ovsdb/ovsdb-idlc.in
> -+++ b/ovsdb/ovsdb-idlc.in
> -@@ -176,7 +176,7 @@ def replace_cplusplus_keyword(schema):
> - 'wchar_t', 'while', 'xor', 'xor_eq'}
> -
> - for tableName, table in schema.tables.items():
> -- for columnName in table.columns:
> -+ for columnName in list(table.columns):
> - if columnName in keywords:
> - table.columns[columnName + '_'] = table.columns.pop(columnName)
> -
> ---
> -2.7.4
> -
> diff --git a/recipes-networking/openvswitch/openvswitch_git.bb b/recipes-networking/openvswitch/openvswitch_git.bb
> index 141a609..07258be 100644
> --- a/recipes-networking/openvswitch/openvswitch_git.bb
> +++ b/recipes-networking/openvswitch/openvswitch_git.bb
> @@ -5,7 +5,7 @@ DEPENDS += "virtual/kernel"
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> RDEPENDS_${PN}-ptest += "\
> - python3-logging python3-syslog python3-io \
> + python3-logging python3-syslog python3-io python3-core \
> python3-fcntl python3-shell python3-xml python3-math \
> python3-datetime python3-netclient python3 sed \
> ldd perl-module-socket perl-module-carp perl-module-exporter \
> @@ -14,26 +14,23 @@ RDEPENDS_${PN}-ptest += "\
> "
>
> S = "${WORKDIR}/git"
> -PV = "2.12+${SRCPV}"
> +PV = "2.13+${SRCPV}"
>
> FILESEXTRAPATHS_append := "${THISDIR}/${PN}-git:"
>
> -SRCREV = "6beb94976e2b3e0c51430b63214de14186d8db39"
> +SRCREV = "71d553b995d0bd527d3ab1e9fbaf5a2ae34de2f3"
> SRC_URI = "file://openvswitch-switch \
> file://openvswitch-switch-setup \
> file://openvswitch-testcontroller \
> file://openvswitch-testcontroller-setup \
> - git://github.com/openvswitch/ovs.git;protocol=git;branch=branch-2.12 \
> - file://openvswitch-add-ptest-6beb94976e2b3e0c51430b63214de14186d8db39.patch \
> + git://github.com/openvswitch/ovs.git;protocol=git;branch=branch-2.13 \
> + file://openvswitch-add-ptest-71d553b995d0bd527d3ab1e9fbaf5a2ae34de2f3.patch \
> file://run-ptest \
> file://disable_m4_check.patch \
> file://kernel_module.patch \
> - file://python-make-remaining-scripts-use-usr-bin-env.patch \
> - file://0002-Define-WAIT_ANY-if-not-provided-by-system.patch \
> file://python-switch-remaining-scripts-to-use-python3.patch \
> file://systemd-update-tool-paths.patch \
> file://systemd-create-runtime-dirs.patch \
> - file://ovsdb-idlc.in-fix-dict-change-during-iteration.patch \
> "
>
> LIC_FILES_CHKSUM = "file://LICENSE;md5=1ce5d23a6429dff345518758f13aaeab"
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 1/7] Revert "tty: serial: fsl_lpuart: drop EARLYCON_DECLARE"
From: Michael Walle @ 2020-02-20 17:43 UTC (permalink / raw)
To: linux-serial, devicetree, linux-kernel, linux-arm-kernel
Cc: Mark Rutland, Peng Fan, Greg Kroah-Hartman, Li Yang,
Michael Walle, Rob Herring, Yuan Yao, Vabhav Sharma, Jiri Slaby,
Shawn Guo
This reverts commit a659652f6169240a5818cb244b280c5a362ef5a4.
This broke the earlycon on LS1021A processors because the order of the
earlycon_setup() functions were changed. Before the commit the normal
lpuart32_early_console_setup() was called. After the commit the
lpuart32_imx_early_console_setup() is called instead.
Fixes: a659652f6169 ("tty: serial: fsl_lpuart: drop EARLYCON_DECLARE")
Signed-off-by: Michael Walle <michael@walle.cc>
---
drivers/tty/serial/fsl_lpuart.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 91e2805e6441..27fdc131c352 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -2390,6 +2390,8 @@ static int __init lpuart32_imx_early_console_setup(struct earlycon_device *devic
OF_EARLYCON_DECLARE(lpuart, "fsl,vf610-lpuart", lpuart_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,ls1021a-lpuart", lpuart32_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,imx7ulp-lpuart", lpuart32_imx_early_console_setup);
+EARLYCON_DECLARE(lpuart, lpuart_early_console_setup);
+EARLYCON_DECLARE(lpuart32, lpuart32_early_console_setup);
#define LPUART_CONSOLE (&lpuart_console)
#define LPUART32_CONSOLE (&lpuart32_console)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [meta-virtualization] [PATCH] docker-ce: allow custom build tags via packageconfig
From: Bruce Ashfield @ 2020-02-20 17:43 UTC (permalink / raw)
To: Ricardo Salveti; +Cc: meta-virtualization
In-Reply-To: <20200218225913.30838-1-ricardo@foundries.io>
merged.
Bruce
In message: [meta-virtualization] [PATCH] docker-ce: allow custom build tags via packageconfig
on 18/02/2020 Ricardo Salveti wrote:
> As done by the docker-moby recipe, move the definition of the default
> build tags outside do_compile and let the docker build tags be
> customized via the packageconfig options set by the recipe.
>
> This is required for enabling seccomp support during build time.
>
> Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
> ---
> recipes-containers/docker/docker-ce_git.bb | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-containers/docker/docker-ce_git.bb b/recipes-containers/docker/docker-ce_git.bb
> index ef84069..3c8a339 100644
> --- a/recipes-containers/docker/docker-ce_git.bb
> +++ b/recipes-containers/docker/docker-ce_git.bb
> @@ -44,6 +44,8 @@ PV = "${DOCKER_VERSION}+git${SRCREV_docker}"
> PACKAGES =+ "${PN}-contrib"
>
> DOCKER_PKG="github.com/docker/docker"
> +# in order to exclude devicemapper and btrfs - https://github.com/docker/docker/issues/14056
> +BUILD_TAGS = "exclude_graphdriver_btrfs exclude_graphdriver_devicemapper"
>
> inherit go
> inherit goarch
> @@ -71,8 +73,7 @@ do_compile() {
> export CGO_ENABLED="1"
> export CGO_CFLAGS="${CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> export CGO_LDFLAGS="${LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> - # in order to exclude devicemapper and btrfs - https://github.com/docker/docker/issues/14056
> - export DOCKER_BUILDTAGS='exclude_graphdriver_btrfs exclude_graphdriver_devicemapper'
> + export DOCKER_BUILDTAGS='${BUILD_TAGS} ${PACKAGECONFIG_CONFARGS}'
>
> export DISABLE_WARN_OUTSIDE_CONTAINER=1
>
> --
> 2.25.0
>
>
^ permalink raw reply
* Re: [meta-virtualization][PATCH] hook_support.py: convert to python3
From: Bruce Ashfield @ 2020-02-20 17:43 UTC (permalink / raw)
To: Changqing Li; +Cc: meta-virtualization
In-Reply-To: <1582011834-136295-1-git-send-email-changqing.li@windriver.com>
merged.
Bruce
In message: [meta-virtualization][PATCH] hook_support.py: convert to python3
on 18/02/2020 Changqing Li wrote:
> From: Changqing Li <changqing.li@windriver.com>
>
> python2 has been removed from oe-core, convert the scripts
> to python3 to avoid runtime error like:
> /usr/bin/env: 'python': No such file or directory'
>
> Signed-off-by: Changqing Li <changqing.li@windriver.com>
> ---
> recipes-extended/libvirt/libvirt/hook_support.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-extended/libvirt/libvirt/hook_support.py b/recipes-extended/libvirt/libvirt/hook_support.py
> index c3eb8b3..7c5e2a9 100755
> --- a/recipes-extended/libvirt/libvirt/hook_support.py
> +++ b/recipes-extended/libvirt/libvirt/hook_support.py
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python
> +#!/usr/bin/env python3
> #
> # Copyright (C) 2014 Wind River Systems, Inc.
> #
> --
> 2.7.4
>
>
^ permalink raw reply
* Re: [PATCH] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads
From: Ondřej Jirman @ 2020-02-20 17:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: Samuel Holland, open list, Stephen Boyd, linux-sunxi,
Chen-Yu Tsai, moderated list:ARM/Allwinner sunXi SoC support
In-Reply-To: <20200220173213.s2ytf3zdi6q3bxli@gilmour.lan>
Hi,
On Thu, Feb 20, 2020 at 06:32:13PM +0100, Maxime Ripard wrote:
> On Wed, Feb 19, 2020 at 02:09:50AM +0100, Ondrej Jirman wrote:
> > When doing a 16-bit read that returns data in the MSB byte, the
> > RSB_DATA register will keep the MSB byte unchanged when doing
> > the following 8-bit read. sunxi_rsb_read() will then return
> > a result that contains high byte from 16-bit read mixed with
> > the 8-bit result.
> >
> > The consequence is that after this happens the PMIC's regmap will
> > look like this: (0x33 is the high byte from the 16-bit read)
> >
> > % cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
> > 00: 33
> > 01: 33
> > 02: 33
> > 03: 33
> > 04: 33
> > 05: 33
> > 06: 33
> > 07: 33
> > 08: 33
> > 09: 33
> > 0a: 33
> > 0b: 33
> > 0c: 33
> > 0d: 33
> > 0e: 33
> > [snip]
> >
> > Fix this by masking the result of the read with the correct mask
> > based on the size of the read. There are no 16-bit users in the
> > mainline kernel, so this doesn't need to get into the stable tree.
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > drivers/bus/sunxi-rsb.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
> > index b8043b58568ac..8ab6a3865f569 100644
> > --- a/drivers/bus/sunxi-rsb.c
> > +++ b/drivers/bus/sunxi-rsb.c
> > @@ -316,6 +316,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
> > {
> > u32 cmd;
> > int ret;
> > + u32 mask;
> >
> > if (!buf)
> > return -EINVAL;
> > @@ -323,12 +324,15 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
> > switch (len) {
> > case 1:
> > cmd = RSB_CMD_RD8;
> > + mask = 0xffu;
> > break;
> > case 2:
> > cmd = RSB_CMD_RD16;
> > + mask = 0xffffu;
> > break;
> > case 4:
> > cmd = RSB_CMD_RD32;
> > + mask = 0xffffffffu;
> > break;
> > default:
> > dev_err(rsb->dev, "Invalid access width: %zd\n", len);
> > @@ -345,7 +349,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
> > if (ret)
> > goto unlock;
> >
> > - *buf = readl(rsb->regs + RSB_DATA);
> > + *buf = readl(rsb->regs + RSB_DATA) & mask;
>
> Thanks for debugging this and the extensive commit log.
>
> I guess it would be cleaner to just use GENMASK(len * 8, 0) here?
GENMASK most probably fails with value (32,0) I think.
#define GENMASK(h, l) \
(((~UL(0)) - (UL(1) << (l)) + 1) & \
(~UL(0) >> (BITS_PER_LONG - 1 - (h))))
would give ~0 >> -1
regards,
o.
> Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads
From: Ondřej Jirman @ 2020-02-20 17:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-sunxi, Chen-Yu Tsai, Samuel Holland, Stephen Boyd,
moderated list:ARM/Allwinner sunXi SoC support, open list
In-Reply-To: <20200220173213.s2ytf3zdi6q3bxli@gilmour.lan>
Hi,
On Thu, Feb 20, 2020 at 06:32:13PM +0100, Maxime Ripard wrote:
> On Wed, Feb 19, 2020 at 02:09:50AM +0100, Ondrej Jirman wrote:
> > When doing a 16-bit read that returns data in the MSB byte, the
> > RSB_DATA register will keep the MSB byte unchanged when doing
> > the following 8-bit read. sunxi_rsb_read() will then return
> > a result that contains high byte from 16-bit read mixed with
> > the 8-bit result.
> >
> > The consequence is that after this happens the PMIC's regmap will
> > look like this: (0x33 is the high byte from the 16-bit read)
> >
> > % cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
> > 00: 33
> > 01: 33
> > 02: 33
> > 03: 33
> > 04: 33
> > 05: 33
> > 06: 33
> > 07: 33
> > 08: 33
> > 09: 33
> > 0a: 33
> > 0b: 33
> > 0c: 33
> > 0d: 33
> > 0e: 33
> > [snip]
> >
> > Fix this by masking the result of the read with the correct mask
> > based on the size of the read. There are no 16-bit users in the
> > mainline kernel, so this doesn't need to get into the stable tree.
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > drivers/bus/sunxi-rsb.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
> > index b8043b58568ac..8ab6a3865f569 100644
> > --- a/drivers/bus/sunxi-rsb.c
> > +++ b/drivers/bus/sunxi-rsb.c
> > @@ -316,6 +316,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
> > {
> > u32 cmd;
> > int ret;
> > + u32 mask;
> >
> > if (!buf)
> > return -EINVAL;
> > @@ -323,12 +324,15 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
> > switch (len) {
> > case 1:
> > cmd = RSB_CMD_RD8;
> > + mask = 0xffu;
> > break;
> > case 2:
> > cmd = RSB_CMD_RD16;
> > + mask = 0xffffu;
> > break;
> > case 4:
> > cmd = RSB_CMD_RD32;
> > + mask = 0xffffffffu;
> > break;
> > default:
> > dev_err(rsb->dev, "Invalid access width: %zd\n", len);
> > @@ -345,7 +349,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
> > if (ret)
> > goto unlock;
> >
> > - *buf = readl(rsb->regs + RSB_DATA);
> > + *buf = readl(rsb->regs + RSB_DATA) & mask;
>
> Thanks for debugging this and the extensive commit log.
>
> I guess it would be cleaner to just use GENMASK(len * 8, 0) here?
GENMASK most probably fails with value (32,0) I think.
#define GENMASK(h, l) \
(((~UL(0)) - (UL(1) << (l)) + 1) & \
(~UL(0) >> (BITS_PER_LONG - 1 - (h))))
would give ~0 >> -1
regards,
o.
> Maxime
^ permalink raw reply
* Re: [PATCHv10 11/13] PCI: mobiveil: Add PCIe Gen4 RC driver for NXP Layerscape SoCs
From: Andrew Murray @ 2020-02-20 17:43 UTC (permalink / raw)
To: Zhiqiang Hou
Cc: mark.rutland, devicetree, lorenzo.pieralisi, m.karthikeyan, arnd,
linux-pci, l.subrahmanya, will.deacon, linux-kernel, leoyang.li,
Minghuan.Lian, robh+dt, Mingkai.Hu, Xiaowei.Bao, catalin.marinas,
bhelgaas, andrew.murray, shawnguo, linux-arm-kernel
In-Reply-To: <20200213040644.45858-12-Zhiqiang.Hou@nxp.com>
On Thu, Feb 13, 2020 at 12:06:42PM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>
> This PCIe controller is based on the Mobiveil GPEX IP, which is
> compatible with the PCI Express™ Base Specification, Revision 4.0.
>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> Reviewed-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
> ---
> V10:
> - Changed the return type of ls_pcie_g4_reinit_hw() to void.
> - Moved Header Type check to mobiveil_pcie_host_probe().
>
> drivers/pci/controller/mobiveil/Kconfig | 9 +
> drivers/pci/controller/mobiveil/Makefile | 1 +
> .../mobiveil/pcie-layerscape-gen4.c | 267 ++++++++++++++++++
> .../pci/controller/mobiveil/pcie-mobiveil.h | 16 +-
> 4 files changed, 291 insertions(+), 2 deletions(-)
> create mode 100644 drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
>
> diff --git a/drivers/pci/controller/mobiveil/Kconfig b/drivers/pci/controller/mobiveil/Kconfig
> index 54161d4ddb11..7439991ee82c 100644
> --- a/drivers/pci/controller/mobiveil/Kconfig
> +++ b/drivers/pci/controller/mobiveil/Kconfig
> @@ -21,4 +21,13 @@ config PCIE_MOBIVEIL_PLAT
> Soft IP. It has up to 8 outbound and inbound windows
> for address translation and it is a PCIe Gen4 IP.
>
> +config PCIE_LAYERSCAPE_GEN4
> + bool "Freescale Layerscape PCIe Gen4 controller"
> + depends on PCI
> + depends on OF && (ARM64 || ARCH_LAYERSCAPE)
> + depends on PCI_MSI_IRQ_DOMAIN
> + select PCIE_MOBIVEIL_HOST
> + help
> + Say Y here if you want PCIe Gen4 controller support on
> + Layerscape SoCs.
> endmenu
> diff --git a/drivers/pci/controller/mobiveil/Makefile b/drivers/pci/controller/mobiveil/Makefile
> index 9fb6d1c6504d..99d879de32d6 100644
> --- a/drivers/pci/controller/mobiveil/Makefile
> +++ b/drivers/pci/controller/mobiveil/Makefile
> @@ -2,3 +2,4 @@
> obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
> obj-$(CONFIG_PCIE_MOBIVEIL_HOST) += pcie-mobiveil-host.o
> obj-$(CONFIG_PCIE_MOBIVEIL_PLAT) += pcie-mobiveil-plat.o
> +obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie-layerscape-gen4.o
> diff --git a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
> new file mode 100644
> index 000000000000..f3bd5f5ad229
> --- /dev/null
> +++ b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
> @@ -0,0 +1,267 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PCIe Gen4 host controller driver for NXP Layerscape SoCs
> + *
> + * Copyright 2019-2020 NXP
> + *
> + * Author: Zhiqiang Hou <Zhiqiang.Hou@nxp.com>
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/interrupt.h>
> +#include <linux/init.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/resource.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +
> +#include "pcie-mobiveil.h"
> +
> +/* LUT and PF control registers */
> +#define PCIE_LUT_OFF 0x80000
> +#define PCIE_PF_OFF 0xc0000
> +#define PCIE_PF_INT_STAT 0x18
> +#define PF_INT_STAT_PABRST BIT(31)
> +
> +#define PCIE_PF_DBG 0x7fc
> +#define PF_DBG_LTSSM_MASK 0x3f
> +#define PF_DBG_LTSSM_L0 0x2d /* L0 state */
> +#define PF_DBG_WE BIT(31)
> +#define PF_DBG_PABR BIT(27)
> +
> +#define to_ls_pcie_g4(x) platform_get_drvdata((x)->pdev)
> +
> +struct ls_pcie_g4 {
> + struct mobiveil_pcie pci;
> + struct delayed_work dwork;
> + int irq;
> +};
> +
> +static inline u32 ls_pcie_g4_lut_readl(struct ls_pcie_g4 *pcie, u32 off)
> +{
> + return ioread32(pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
> +}
> +
> +static inline void ls_pcie_g4_lut_writel(struct ls_pcie_g4 *pcie,
> + u32 off, u32 val)
> +{
> + iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
> +}
> +
> +static inline u32 ls_pcie_g4_pf_readl(struct ls_pcie_g4 *pcie, u32 off)
> +{
> + return ioread32(pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
> +}
> +
> +static inline void ls_pcie_g4_pf_writel(struct ls_pcie_g4 *pcie,
> + u32 off, u32 val)
> +{
> + iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
> +}
> +
> +static int ls_pcie_g4_link_up(struct mobiveil_pcie *pci)
> +{
> + struct ls_pcie_g4 *pcie = to_ls_pcie_g4(pci);
> + u32 state;
> +
> + state = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
> + state = state & PF_DBG_LTSSM_MASK;
> +
> + if (state == PF_DBG_LTSSM_L0)
> + return 1;
> +
> + return 0;
> +}
> +
> +static void ls_pcie_g4_disable_interrupt(struct ls_pcie_g4 *pcie)
> +{
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> +
> + mobiveil_csr_writel(mv_pci, 0, PAB_INTP_AMBA_MISC_ENB);
> +}
> +
> +static void ls_pcie_g4_enable_interrupt(struct ls_pcie_g4 *pcie)
> +{
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> + u32 val;
> +
> + /* Clear the interrupt status */
> + mobiveil_csr_writel(mv_pci, 0xffffffff, PAB_INTP_AMBA_MISC_STAT);
> +
> + val = PAB_INTP_INTX_MASK | PAB_INTP_MSI | PAB_INTP_RESET |
> + PAB_INTP_PCIE_UE | PAB_INTP_IE_PMREDI | PAB_INTP_IE_EC;
> + mobiveil_csr_writel(mv_pci, val, PAB_INTP_AMBA_MISC_ENB);
> +}
> +
> +static int ls_pcie_g4_reinit_hw(struct ls_pcie_g4 *pcie)
> +{
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> + struct device *dev = &mv_pci->pdev->dev;
> + u32 val, act_stat;
> + int to = 100;
> +
> + /* Poll for pab_csb_reset to set and PAB activity to clear */
> + do {
> + usleep_range(10, 15);
> + val = ls_pcie_g4_pf_readl(pcie, PCIE_PF_INT_STAT);
> + act_stat = mobiveil_csr_readl(mv_pci, PAB_ACTIVITY_STAT);
> + } while (((val & PF_INT_STAT_PABRST) == 0 || act_stat) && to--);
> + if (to < 0) {
> + dev_err(dev, "Poll PABRST&PABACT timeout\n");
> + return -EIO;
> + }
> +
> + /* clear PEX_RESET bit in PEX_PF0_DBG register */
> + val = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
> + val |= PF_DBG_WE;
> + ls_pcie_g4_pf_writel(pcie, PCIE_PF_DBG, val);
> +
> + val = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
> + val |= PF_DBG_PABR;
> + ls_pcie_g4_pf_writel(pcie, PCIE_PF_DBG, val);
> +
> + val = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
> + val &= ~PF_DBG_WE;
> + ls_pcie_g4_pf_writel(pcie, PCIE_PF_DBG, val);
> +
> + mobiveil_host_init(mv_pci, true);
> +
> + to = 100;
> + while (!ls_pcie_g4_link_up(mv_pci) && to--)
> + usleep_range(200, 250);
> + if (to < 0) {
> + dev_err(dev, "PCIe link training timeout\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static irqreturn_t ls_pcie_g4_isr(int irq, void *dev_id)
> +{
> + struct ls_pcie_g4 *pcie = (struct ls_pcie_g4 *)dev_id;
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> + u32 val;
> +
> + val = mobiveil_csr_readl(mv_pci, PAB_INTP_AMBA_MISC_STAT);
> + if (!val)
> + return IRQ_NONE;
> +
> + if (val & PAB_INTP_RESET) {
> + ls_pcie_g4_disable_interrupt(pcie);
> + schedule_delayed_work(&pcie->dwork, msecs_to_jiffies(1));
> + }
> +
> + mobiveil_csr_writel(mv_pci, val, PAB_INTP_AMBA_MISC_STAT);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int ls_pcie_g4_interrupt_init(struct mobiveil_pcie *mv_pci)
> +{
> + struct ls_pcie_g4 *pcie = to_ls_pcie_g4(mv_pci);
> + struct platform_device *pdev = mv_pci->pdev;
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + pcie->irq = platform_get_irq_byname(pdev, "intr");
> + if (pcie->irq < 0) {
> + dev_err(dev, "Can't get 'intr' IRQ, errno = %d\n", pcie->irq);
> + return pcie->irq;
> + }
> + ret = devm_request_irq(dev, pcie->irq, ls_pcie_g4_isr,
> + IRQF_SHARED, pdev->name, pcie);
> + if (ret) {
> + dev_err(dev, "Can't register PCIe IRQ, errno = %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void ls_pcie_g4_reset(struct work_struct *work)
> +{
> + struct delayed_work *dwork = container_of(work, struct delayed_work,
> + work);
> + struct ls_pcie_g4 *pcie = container_of(dwork, struct ls_pcie_g4, dwork);
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> + u16 ctrl;
> +
> + ctrl = mobiveil_csr_readw(mv_pci, PCI_BRIDGE_CONTROL);
> + ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
> + mobiveil_csr_writew(mv_pci, ctrl, PCI_BRIDGE_CONTROL);
> +
> + if (!ls_pcie_g4_reinit_hw(pcie))
> + return;
> +
> + ls_pcie_g4_enable_interrupt(pcie);
> +}
> +
> +static struct mobiveil_rp_ops ls_pcie_g4_rp_ops = {
> + .interrupt_init = ls_pcie_g4_interrupt_init,
> +};
> +
> +static const struct mobiveil_pab_ops ls_pcie_g4_pab_ops = {
> + .link_up = ls_pcie_g4_link_up,
> +};
> +
> +static int __init ls_pcie_g4_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct pci_host_bridge *bridge;
> + struct mobiveil_pcie *mv_pci;
> + struct ls_pcie_g4 *pcie;
> + struct device_node *np = dev->of_node;
> + int ret;
> +
> + if (!of_parse_phandle(np, "msi-parent", 0)) {
> + dev_err(dev, "Failed to find msi-parent\n");
> + return -EINVAL;
> + }
> +
> + bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> + if (!bridge)
> + return -ENOMEM;
> +
> + pcie = pci_host_bridge_priv(bridge);
> + mv_pci = &pcie->pci;
> +
> + mv_pci->pdev = pdev;
> + mv_pci->ops = &ls_pcie_g4_pab_ops;
> + mv_pci->rp.ops = &ls_pcie_g4_rp_ops;
> + mv_pci->rp.bridge = bridge;
> +
> + platform_set_drvdata(pdev, pcie);
> +
> + INIT_DELAYED_WORK(&pcie->dwork, ls_pcie_g4_reset);
> +
> + ret = mobiveil_pcie_host_probe(mv_pci);
> + if (ret) {
> + dev_err(dev, "Fail to probe\n");
> + return ret;
> + }
> +
> + ls_pcie_g4_enable_interrupt(pcie);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ls_pcie_g4_of_match[] = {
> + { .compatible = "fsl,lx2160a-pcie", },
> + { },
> +};
> +
> +static struct platform_driver ls_pcie_g4_driver = {
> + .driver = {
> + .name = "layerscape-pcie-gen4",
> + .of_match_table = ls_pcie_g4_of_match,
> + .suppress_bind_attrs = true,
> + },
> +};
> +
> +builtin_platform_driver_probe(ls_pcie_g4_driver, ls_pcie_g4_probe);
> diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> index 72c62b4d8f7b..7b6a403a9fc0 100644
> --- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> +++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> @@ -43,6 +43,8 @@
> #define PAGE_LO_MASK 0x3ff
> #define PAGE_SEL_OFFSET_SHIFT 10
>
> +#define PAB_ACTIVITY_STAT 0x81c
> +
> #define PAB_AXI_PIO_CTRL 0x0840
> #define APIO_EN_MASK 0xf
>
> @@ -51,8 +53,18 @@
>
> #define PAB_INTP_AMBA_MISC_ENB 0x0b0c
> #define PAB_INTP_AMBA_MISC_STAT 0x0b1c
> -#define PAB_INTP_INTX_MASK 0x01e0
> -#define PAB_INTP_MSI_MASK 0x8
> +#define PAB_INTP_RESET BIT(1)
> +#define PAB_INTP_MSI BIT(3)
> +#define PAB_INTP_INTA BIT(5)
> +#define PAB_INTP_INTB BIT(6)
> +#define PAB_INTP_INTC BIT(7)
> +#define PAB_INTP_INTD BIT(8)
> +#define PAB_INTP_PCIE_UE BIT(9)
> +#define PAB_INTP_IE_PMREDI BIT(29)
> +#define PAB_INTP_IE_EC BIT(30)
> +#define PAB_INTP_MSI_MASK PAB_INTP_MSI
> +#define PAB_INTP_INTX_MASK (PAB_INTP_INTA | PAB_INTP_INTB |\
> + PAB_INTP_INTC | PAB_INTP_INTD)
>
> #define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win)
> #define WIN_ENABLE_SHIFT 0
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv10 11/13] PCI: mobiveil: Add PCIe Gen4 RC driver for NXP Layerscape SoCs
From: Andrew Murray @ 2020-02-20 17:43 UTC (permalink / raw)
To: Zhiqiang Hou
Cc: linux-pci, linux-arm-kernel, devicetree, linux-kernel, bhelgaas,
robh+dt, andrew.murray, arnd, mark.rutland, l.subrahmanya,
shawnguo, m.karthikeyan, leoyang.li, lorenzo.pieralisi,
catalin.marinas, will.deacon, Mingkai.Hu, Minghuan.Lian,
Xiaowei.Bao
In-Reply-To: <20200213040644.45858-12-Zhiqiang.Hou@nxp.com>
On Thu, Feb 13, 2020 at 12:06:42PM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>
> This PCIe controller is based on the Mobiveil GPEX IP, which is
> compatible with the PCI Express™ Base Specification, Revision 4.0.
>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> Reviewed-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
> ---
> V10:
> - Changed the return type of ls_pcie_g4_reinit_hw() to void.
> - Moved Header Type check to mobiveil_pcie_host_probe().
>
> drivers/pci/controller/mobiveil/Kconfig | 9 +
> drivers/pci/controller/mobiveil/Makefile | 1 +
> .../mobiveil/pcie-layerscape-gen4.c | 267 ++++++++++++++++++
> .../pci/controller/mobiveil/pcie-mobiveil.h | 16 +-
> 4 files changed, 291 insertions(+), 2 deletions(-)
> create mode 100644 drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
>
> diff --git a/drivers/pci/controller/mobiveil/Kconfig b/drivers/pci/controller/mobiveil/Kconfig
> index 54161d4ddb11..7439991ee82c 100644
> --- a/drivers/pci/controller/mobiveil/Kconfig
> +++ b/drivers/pci/controller/mobiveil/Kconfig
> @@ -21,4 +21,13 @@ config PCIE_MOBIVEIL_PLAT
> Soft IP. It has up to 8 outbound and inbound windows
> for address translation and it is a PCIe Gen4 IP.
>
> +config PCIE_LAYERSCAPE_GEN4
> + bool "Freescale Layerscape PCIe Gen4 controller"
> + depends on PCI
> + depends on OF && (ARM64 || ARCH_LAYERSCAPE)
> + depends on PCI_MSI_IRQ_DOMAIN
> + select PCIE_MOBIVEIL_HOST
> + help
> + Say Y here if you want PCIe Gen4 controller support on
> + Layerscape SoCs.
> endmenu
> diff --git a/drivers/pci/controller/mobiveil/Makefile b/drivers/pci/controller/mobiveil/Makefile
> index 9fb6d1c6504d..99d879de32d6 100644
> --- a/drivers/pci/controller/mobiveil/Makefile
> +++ b/drivers/pci/controller/mobiveil/Makefile
> @@ -2,3 +2,4 @@
> obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
> obj-$(CONFIG_PCIE_MOBIVEIL_HOST) += pcie-mobiveil-host.o
> obj-$(CONFIG_PCIE_MOBIVEIL_PLAT) += pcie-mobiveil-plat.o
> +obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie-layerscape-gen4.o
> diff --git a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
> new file mode 100644
> index 000000000000..f3bd5f5ad229
> --- /dev/null
> +++ b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
> @@ -0,0 +1,267 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PCIe Gen4 host controller driver for NXP Layerscape SoCs
> + *
> + * Copyright 2019-2020 NXP
> + *
> + * Author: Zhiqiang Hou <Zhiqiang.Hou@nxp.com>
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/interrupt.h>
> +#include <linux/init.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/resource.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +
> +#include "pcie-mobiveil.h"
> +
> +/* LUT and PF control registers */
> +#define PCIE_LUT_OFF 0x80000
> +#define PCIE_PF_OFF 0xc0000
> +#define PCIE_PF_INT_STAT 0x18
> +#define PF_INT_STAT_PABRST BIT(31)
> +
> +#define PCIE_PF_DBG 0x7fc
> +#define PF_DBG_LTSSM_MASK 0x3f
> +#define PF_DBG_LTSSM_L0 0x2d /* L0 state */
> +#define PF_DBG_WE BIT(31)
> +#define PF_DBG_PABR BIT(27)
> +
> +#define to_ls_pcie_g4(x) platform_get_drvdata((x)->pdev)
> +
> +struct ls_pcie_g4 {
> + struct mobiveil_pcie pci;
> + struct delayed_work dwork;
> + int irq;
> +};
> +
> +static inline u32 ls_pcie_g4_lut_readl(struct ls_pcie_g4 *pcie, u32 off)
> +{
> + return ioread32(pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
> +}
> +
> +static inline void ls_pcie_g4_lut_writel(struct ls_pcie_g4 *pcie,
> + u32 off, u32 val)
> +{
> + iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
> +}
> +
> +static inline u32 ls_pcie_g4_pf_readl(struct ls_pcie_g4 *pcie, u32 off)
> +{
> + return ioread32(pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
> +}
> +
> +static inline void ls_pcie_g4_pf_writel(struct ls_pcie_g4 *pcie,
> + u32 off, u32 val)
> +{
> + iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
> +}
> +
> +static int ls_pcie_g4_link_up(struct mobiveil_pcie *pci)
> +{
> + struct ls_pcie_g4 *pcie = to_ls_pcie_g4(pci);
> + u32 state;
> +
> + state = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
> + state = state & PF_DBG_LTSSM_MASK;
> +
> + if (state == PF_DBG_LTSSM_L0)
> + return 1;
> +
> + return 0;
> +}
> +
> +static void ls_pcie_g4_disable_interrupt(struct ls_pcie_g4 *pcie)
> +{
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> +
> + mobiveil_csr_writel(mv_pci, 0, PAB_INTP_AMBA_MISC_ENB);
> +}
> +
> +static void ls_pcie_g4_enable_interrupt(struct ls_pcie_g4 *pcie)
> +{
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> + u32 val;
> +
> + /* Clear the interrupt status */
> + mobiveil_csr_writel(mv_pci, 0xffffffff, PAB_INTP_AMBA_MISC_STAT);
> +
> + val = PAB_INTP_INTX_MASK | PAB_INTP_MSI | PAB_INTP_RESET |
> + PAB_INTP_PCIE_UE | PAB_INTP_IE_PMREDI | PAB_INTP_IE_EC;
> + mobiveil_csr_writel(mv_pci, val, PAB_INTP_AMBA_MISC_ENB);
> +}
> +
> +static int ls_pcie_g4_reinit_hw(struct ls_pcie_g4 *pcie)
> +{
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> + struct device *dev = &mv_pci->pdev->dev;
> + u32 val, act_stat;
> + int to = 100;
> +
> + /* Poll for pab_csb_reset to set and PAB activity to clear */
> + do {
> + usleep_range(10, 15);
> + val = ls_pcie_g4_pf_readl(pcie, PCIE_PF_INT_STAT);
> + act_stat = mobiveil_csr_readl(mv_pci, PAB_ACTIVITY_STAT);
> + } while (((val & PF_INT_STAT_PABRST) == 0 || act_stat) && to--);
> + if (to < 0) {
> + dev_err(dev, "Poll PABRST&PABACT timeout\n");
> + return -EIO;
> + }
> +
> + /* clear PEX_RESET bit in PEX_PF0_DBG register */
> + val = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
> + val |= PF_DBG_WE;
> + ls_pcie_g4_pf_writel(pcie, PCIE_PF_DBG, val);
> +
> + val = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
> + val |= PF_DBG_PABR;
> + ls_pcie_g4_pf_writel(pcie, PCIE_PF_DBG, val);
> +
> + val = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
> + val &= ~PF_DBG_WE;
> + ls_pcie_g4_pf_writel(pcie, PCIE_PF_DBG, val);
> +
> + mobiveil_host_init(mv_pci, true);
> +
> + to = 100;
> + while (!ls_pcie_g4_link_up(mv_pci) && to--)
> + usleep_range(200, 250);
> + if (to < 0) {
> + dev_err(dev, "PCIe link training timeout\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static irqreturn_t ls_pcie_g4_isr(int irq, void *dev_id)
> +{
> + struct ls_pcie_g4 *pcie = (struct ls_pcie_g4 *)dev_id;
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> + u32 val;
> +
> + val = mobiveil_csr_readl(mv_pci, PAB_INTP_AMBA_MISC_STAT);
> + if (!val)
> + return IRQ_NONE;
> +
> + if (val & PAB_INTP_RESET) {
> + ls_pcie_g4_disable_interrupt(pcie);
> + schedule_delayed_work(&pcie->dwork, msecs_to_jiffies(1));
> + }
> +
> + mobiveil_csr_writel(mv_pci, val, PAB_INTP_AMBA_MISC_STAT);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int ls_pcie_g4_interrupt_init(struct mobiveil_pcie *mv_pci)
> +{
> + struct ls_pcie_g4 *pcie = to_ls_pcie_g4(mv_pci);
> + struct platform_device *pdev = mv_pci->pdev;
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + pcie->irq = platform_get_irq_byname(pdev, "intr");
> + if (pcie->irq < 0) {
> + dev_err(dev, "Can't get 'intr' IRQ, errno = %d\n", pcie->irq);
> + return pcie->irq;
> + }
> + ret = devm_request_irq(dev, pcie->irq, ls_pcie_g4_isr,
> + IRQF_SHARED, pdev->name, pcie);
> + if (ret) {
> + dev_err(dev, "Can't register PCIe IRQ, errno = %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void ls_pcie_g4_reset(struct work_struct *work)
> +{
> + struct delayed_work *dwork = container_of(work, struct delayed_work,
> + work);
> + struct ls_pcie_g4 *pcie = container_of(dwork, struct ls_pcie_g4, dwork);
> + struct mobiveil_pcie *mv_pci = &pcie->pci;
> + u16 ctrl;
> +
> + ctrl = mobiveil_csr_readw(mv_pci, PCI_BRIDGE_CONTROL);
> + ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
> + mobiveil_csr_writew(mv_pci, ctrl, PCI_BRIDGE_CONTROL);
> +
> + if (!ls_pcie_g4_reinit_hw(pcie))
> + return;
> +
> + ls_pcie_g4_enable_interrupt(pcie);
> +}
> +
> +static struct mobiveil_rp_ops ls_pcie_g4_rp_ops = {
> + .interrupt_init = ls_pcie_g4_interrupt_init,
> +};
> +
> +static const struct mobiveil_pab_ops ls_pcie_g4_pab_ops = {
> + .link_up = ls_pcie_g4_link_up,
> +};
> +
> +static int __init ls_pcie_g4_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct pci_host_bridge *bridge;
> + struct mobiveil_pcie *mv_pci;
> + struct ls_pcie_g4 *pcie;
> + struct device_node *np = dev->of_node;
> + int ret;
> +
> + if (!of_parse_phandle(np, "msi-parent", 0)) {
> + dev_err(dev, "Failed to find msi-parent\n");
> + return -EINVAL;
> + }
> +
> + bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> + if (!bridge)
> + return -ENOMEM;
> +
> + pcie = pci_host_bridge_priv(bridge);
> + mv_pci = &pcie->pci;
> +
> + mv_pci->pdev = pdev;
> + mv_pci->ops = &ls_pcie_g4_pab_ops;
> + mv_pci->rp.ops = &ls_pcie_g4_rp_ops;
> + mv_pci->rp.bridge = bridge;
> +
> + platform_set_drvdata(pdev, pcie);
> +
> + INIT_DELAYED_WORK(&pcie->dwork, ls_pcie_g4_reset);
> +
> + ret = mobiveil_pcie_host_probe(mv_pci);
> + if (ret) {
> + dev_err(dev, "Fail to probe\n");
> + return ret;
> + }
> +
> + ls_pcie_g4_enable_interrupt(pcie);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ls_pcie_g4_of_match[] = {
> + { .compatible = "fsl,lx2160a-pcie", },
> + { },
> +};
> +
> +static struct platform_driver ls_pcie_g4_driver = {
> + .driver = {
> + .name = "layerscape-pcie-gen4",
> + .of_match_table = ls_pcie_g4_of_match,
> + .suppress_bind_attrs = true,
> + },
> +};
> +
> +builtin_platform_driver_probe(ls_pcie_g4_driver, ls_pcie_g4_probe);
> diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> index 72c62b4d8f7b..7b6a403a9fc0 100644
> --- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> +++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> @@ -43,6 +43,8 @@
> #define PAGE_LO_MASK 0x3ff
> #define PAGE_SEL_OFFSET_SHIFT 10
>
> +#define PAB_ACTIVITY_STAT 0x81c
> +
> #define PAB_AXI_PIO_CTRL 0x0840
> #define APIO_EN_MASK 0xf
>
> @@ -51,8 +53,18 @@
>
> #define PAB_INTP_AMBA_MISC_ENB 0x0b0c
> #define PAB_INTP_AMBA_MISC_STAT 0x0b1c
> -#define PAB_INTP_INTX_MASK 0x01e0
> -#define PAB_INTP_MSI_MASK 0x8
> +#define PAB_INTP_RESET BIT(1)
> +#define PAB_INTP_MSI BIT(3)
> +#define PAB_INTP_INTA BIT(5)
> +#define PAB_INTP_INTB BIT(6)
> +#define PAB_INTP_INTC BIT(7)
> +#define PAB_INTP_INTD BIT(8)
> +#define PAB_INTP_PCIE_UE BIT(9)
> +#define PAB_INTP_IE_PMREDI BIT(29)
> +#define PAB_INTP_IE_EC BIT(30)
> +#define PAB_INTP_MSI_MASK PAB_INTP_MSI
> +#define PAB_INTP_INTX_MASK (PAB_INTP_INTA | PAB_INTP_INTB |\
> + PAB_INTP_INTC | PAB_INTP_INTD)
>
> #define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win)
> #define WIN_ENABLE_SHIFT 0
> --
> 2.17.1
>
^ permalink raw reply
* [igt-dev] ✗ Fi.CI.BAT: failure for i915/gem_eio: Trim kms workload
From: Patchwork @ 2020-02-20 17:43 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20200220165301.1996742-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: i915/gem_eio: Trim kms workload
URL : https://patchwork.freedesktop.org/series/73723/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> IGTPW_4200
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with IGTPW_4200 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_4200, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_4200:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@live_gt_lrc:
- fi-cfl-guc: [PASS][1] -> [DMESG-FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cfl-guc/igt@i915_selftest@live_gt_lrc.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-cfl-guc/igt@i915_selftest@live_gt_lrc.html
New tests
---------
New tests have been introduced between CI_DRM_7973 and IGTPW_4200:
### New IGT tests (4) ###
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 1 dmesg-warn(s) 16 pass(s) 21 skip(s)
- Exec time: [0.0, 0.22] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 1 dmesg-warn(s) 27 pass(s) 10 skip(s)
- Exec time: [0.0, 4.97] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 1 dmesg-warn(s) 27 pass(s) 10 skip(s)
- Exec time: [0.45, 17.95] s
* igt@i915_pm_rps@basic-api:
- Statuses : 33 pass(s) 5 skip(s)
- Exec time: [0.0, 0.02] s
Known issues
------------
Here are the changes found in IGTPW_4200 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [PASS][3] -> [INCOMPLETE][4] ([i915#45])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_close_race@basic-threads.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-byt-n2820/igt@gem_close_race@basic-threads.html
* igt@i915_selftest@live_gtt:
- fi-skl-6600u: [PASS][5] -> [TIMEOUT][6] ([fdo#111732] / [fdo#112271])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-6600u/igt@i915_selftest@live_gtt.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-skl-6600u/igt@i915_selftest@live_gtt.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][7] -> [DMESG-WARN][8] ([i915#44])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
* igt@vgem_basic@debugfs:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([CI#94] / [i915#402])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@vgem_basic@debugfs.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-tgl-y/igt@vgem_basic@debugfs.html
#### Possible fixes ####
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][11] ([i915#877]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][13] ([i915#217]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@prime_self_import@basic-llseek-bad:
- fi-tgl-y: [DMESG-WARN][15] ([CI#94] / [i915#402]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
#### Warnings ####
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [INCOMPLETE][17] ([i915#45]) -> [TIMEOUT][18] ([fdo#112271] / [i915#1084] / [i915#816])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-j1900/igt@gem_close_race@basic-threads.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-byt-j1900/igt@gem_close_race@basic-threads.html
* igt@kms_chamelium@dp-edid-read:
- fi-icl-u3: [SKIP][19] ([fdo#109284] / [fdo#111827]) -> [SKIP][20] ([fdo#109284] / [fdo#111827] / [i915#585])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@kms_chamelium@dp-edid-read.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-icl-u3/igt@kms_chamelium@dp-edid-read.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-icl-u3: [SKIP][21] ([fdo#109284] / [fdo#111827] / [i915#585]) -> [SKIP][22] ([fdo#109284] / [fdo#111827])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@kms_chamelium@dp-hpd-fast.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/fi-icl-u3/igt@kms_chamelium@dp-hpd-fast.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#111732]: https://bugs.freedesktop.org/show_bug.cgi?id=111732
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 42)
------------------------------
Additional (3): fi-kbl-soraka fi-ivb-3770 fi-pnv-d510
Missing (10): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-kbl-7500u fi-ctg-p8600 fi-bsw-kefka fi-bdw-samus fi-snb-2600
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4200
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4200: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/index.html
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4200/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v2] iomap: return partial I/O count on error in iomap_dio_bio_actor
From: Matthew Wilcox @ 2020-02-20 17:42 UTC (permalink / raw)
To: Goldwyn Rodrigues; +Cc: linux-ext4, linux-fsdevel, hch, darrick.wong
In-Reply-To: <20200220152355.5ticlkptc7kwrifz@fiona>
On Thu, Feb 20, 2020 at 09:23:55AM -0600, Goldwyn Rodrigues wrote:
> In case of a block device error, written parameter in iomap_end()
> is zero as opposed to the amount of submitted I/O.
> Filesystems such as btrfs need to account for the I/O in ordered
> extents, even if it resulted in an error. Having (incomplete)
> submitted bytes in written gives the filesystem the amount of data
> which has been submitted before the error occurred, and the
> filesystem code can choose how to use it.
>
> The final returned error for iomap_dio_rw() is set by
> iomap_dio_complete().
>
> Partial writes in direct I/O are considered an error. So,
> ->iomap_end() using written == 0 as error must be changed
> to written < length. In this case, ext4 is the only user.
I really had a hard time understanding this. I think what you meant
was:
Currently, I/Os that complete with an error indicate this by passing
written == 0 to the iomap_end function. However, btrfs needs to know how
many bytes were written for its own accounting. Change the convention
to pass the number of bytes which were actually written, and change the
only user to check for a short write instead of a zero length write.
> Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
> ---
> fs/ext4/inode.c | 2 +-
> fs/iomap/direct-io.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index e60aca791d3f..e50e7414351a 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3475,7 +3475,7 @@ static int ext4_iomap_end(struct inode *inode, loff_t offset, loff_t length,
> * the I/O. Any blocks that may have been allocated in preparation for
> * the direct I/O will be reused during buffered I/O.
> */
> - if (flags & (IOMAP_WRITE | IOMAP_DIRECT) && written == 0)
> + if (flags & (IOMAP_WRITE | IOMAP_DIRECT) && written < length)
> return -ENOTBLK;
>
> return 0;
> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index 41c1e7c20a1f..01865db1bd09 100644
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@ -264,7 +264,7 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
> size_t n;
> if (dio->error) {
> iov_iter_revert(dio->submit.iter, copied);
> - copied = ret = 0;
> + ret = 0;
> goto out;
> }
>
> --
> 2.25.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] compiler: Remove CONFIG_OPTIMIZE_INLINING entirely
From: Nathan Chancellor @ 2020-02-20 17:42 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Andrew Morton, Arnd Bergmann, Ingo Molnar, Thomas Gleixner, x86,
clang-built-linux, Miguel Ojeda, sparclinux, Borislav Petkov,
H. Peter Anvin, linux-kernel
In-Reply-To: <20200220110807.32534-2-masahiroy@kernel.org>
On Thu, Feb 20, 2020 at 08:08:07PM +0900, Masahiro Yamada wrote:
> Commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
> forcibly") made this always-on option. We released v5.4 and v5.5
> including that commit.
>
> Remove the CONFIG option and clean up the code now.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] compiler: Remove CONFIG_OPTIMIZE_INLINING entirely
From: Nathan Chancellor @ 2020-02-20 17:42 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Andrew Morton, Arnd Bergmann, Ingo Molnar, Thomas Gleixner, x86,
clang-built-linux, Miguel Ojeda, sparclinux, Borislav Petkov,
H. Peter Anvin, linux-kernel
In-Reply-To: <20200220110807.32534-2-masahiroy@kernel.org>
On Thu, Feb 20, 2020 at 08:08:07PM +0900, Masahiro Yamada wrote:
> Commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
> forcibly") made this always-on option. We released v5.4 and v5.5
> including that commit.
>
> Remove the CONFIG option and clean up the code now.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
^ permalink raw reply
* [Intel-gfx] [PATCH i-g-t] i915/i915_pm_rpm: Only check for suspend failures after each debugfs entry
From: Chris Wilson @ 2020-02-20 17:41 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
Since we check before and then after each debugfs entry, we do not need
to check before each time as well. We will error out as soon as it does
fail, at all other times we know the system to be idle.
No impact on runtime for glk (which apparently is one of the better
behaving systems).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Martin Peres <martin.peres@linux.intel.com>
---
tests/i915/i915_pm_rpm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
index 0c2821122..bf412b5cc 100644
--- a/tests/i915/i915_pm_rpm.c
+++ b/tests/i915/i915_pm_rpm.c
@@ -932,9 +932,6 @@ static int read_entry(const char *filepath,
int fd;
int rc;
- igt_assert_f(wait_for_suspended(), "Before opening: %s (%s)\n",
- filepath + pathinfo->base, filepath);
-
fd = open(filepath, O_RDONLY | O_NONBLOCK);
if (fd < 0) {
igt_debug("Failed to open '%s': %m\n", filepath);
--
2.25.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH v2 1/2] sparc,x86: vdso: remove meaningless undefining CONFIG_OPTIMIZE_INLINING
From: Nathan Chancellor @ 2020-02-20 17:41 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Andrew Morton, Arnd Bergmann, Ingo Molnar, Thomas Gleixner, x86,
clang-built-linux, Miguel Ojeda, sparclinux, Andy Lutomirski,
Borislav Petkov, David S. Miller, H. Peter Anvin, linux-kernel
In-Reply-To: <20200220110807.32534-1-masahiroy@kernel.org>
On Thu, Feb 20, 2020 at 08:08:06PM +0900, Masahiro Yamada wrote:
> The code, #undef CONFIG_OPTIMIZE_INLINING, is not working as expected
> because <linux/compiler_types.h> is parsed before vclock_gettime.c
> since 28128c61e08e ("kconfig.h: Include compiler types to avoid missed
> struct attributes").
>
> Since then, <linux/compiler_types.h> is included really early by
> using the '-include' option. So, you cannot negate the decision of
> <linux/compiler_types.h> in this way.
>
> You can confirm it by checking the pre-processed code, like this:
>
> $ make arch/x86/entry/vdso/vdso32/vclock_gettime.i
>
> There is no difference with/without CONFIG_CC_OPTIMIZE_FOR_SIZE.
>
> It is about two years since 28128c61e08e. Nobody has reported a
> problem (or, nobody has even noticed the fact that this code is not
> working).
>
> It is ugly and unreliable to attempt to undefine a CONFIG option from
> C files, and anyway the inlining heuristic is up to the compiler.
>
> Just remove the broken code.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
^ permalink raw reply
* Re: [PATCH 17/19] target/arm: Add formats for some vfp 2 and 3-register insns
From: Peter Maydell @ 2020-02-20 17:40 UTC (permalink / raw)
To: Richard Henderson; +Cc: QEMU Developers
In-Reply-To: <20200214181547.21408-18-richard.henderson@linaro.org>
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Those vfp instructions without extra opcode fields can
> share a common @format for brevity.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
> target/arm/vfp.decode | 134 ++++++++++++++++--------------------------
> 1 file changed, 52 insertions(+), 82 deletions(-)
>
> diff --git a/target/arm/vfp.decode b/target/arm/vfp.decode
> index 592fe9e1e4..4f294f88be 100644
> --- a/target/arm/vfp.decode
> +++ b/target/arm/vfp.decode
> @@ -46,6 +46,14 @@
>
> %vmov_imm 16:4 0:4
>
> +@vfp_dnm_s ................................ vm=%vm_sp vn=%vn_sp vd=%vd_sp
> +@vfp_dnm_d ................................ vm=%vm_dp vn=%vn_dp vd=%vd_dp
> +
> +@vfp_dm_ss ................................ vm=%vm_sp vd=%vd_sp
> +@vfp_dm_dd ................................ vm=%vm_dp vd=%vd_dp
> +@vfp_dm_ds ................................ vm=%vm_sp vd=%vd_dp
> +@vfp_dm_sd ................................ vm=%vm_dp vd=%vd_sp
I'm less convinced about the ds and sd ones because there aren't
very many uses of them, and now you have to go back from the
insn line to the format line to check which way round the single
and the double are if you want to confirm that the decode is right.
But anyway
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH v2 1/2] sparc,x86: vdso: remove meaningless undefining CONFIG_OPTIMIZE_INLINING
From: Nathan Chancellor @ 2020-02-20 17:41 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Andrew Morton, Arnd Bergmann, Ingo Molnar, Thomas Gleixner, x86,
clang-built-linux, Miguel Ojeda, sparclinux, Andy Lutomirski,
Borislav Petkov, David S. Miller, H. Peter Anvin, linux-kernel
In-Reply-To: <20200220110807.32534-1-masahiroy@kernel.org>
On Thu, Feb 20, 2020 at 08:08:06PM +0900, Masahiro Yamada wrote:
> The code, #undef CONFIG_OPTIMIZE_INLINING, is not working as expected
> because <linux/compiler_types.h> is parsed before vclock_gettime.c
> since 28128c61e08e ("kconfig.h: Include compiler types to avoid missed
> struct attributes").
>
> Since then, <linux/compiler_types.h> is included really early by
> using the '-include' option. So, you cannot negate the decision of
> <linux/compiler_types.h> in this way.
>
> You can confirm it by checking the pre-processed code, like this:
>
> $ make arch/x86/entry/vdso/vdso32/vclock_gettime.i
>
> There is no difference with/without CONFIG_CC_OPTIMIZE_FOR_SIZE.
>
> It is about two years since 28128c61e08e. Nobody has reported a
> problem (or, nobody has even noticed the fact that this code is not
> working).
>
> It is ugly and unreliable to attempt to undefine a CONFIG option from
> C files, and anyway the inlining heuristic is up to the compiler.
>
> Just remove the broken code.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
^ permalink raw reply
* [igt-dev] [PATCH i-g-t] i915/i915_pm_rpm: Only check for suspend failures after each debugfs entry
From: Chris Wilson @ 2020-02-20 17:41 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
Since we check before and then after each debugfs entry, we do not need
to check before each time as well. We will error out as soon as it does
fail, at all other times we know the system to be idle.
No impact on runtime for glk (which apparently is one of the better
behaving systems).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Martin Peres <martin.peres@linux.intel.com>
---
tests/i915/i915_pm_rpm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
index 0c2821122..bf412b5cc 100644
--- a/tests/i915/i915_pm_rpm.c
+++ b/tests/i915/i915_pm_rpm.c
@@ -932,9 +932,6 @@ static int read_entry(const char *filepath,
int fd;
int rc;
- igt_assert_f(wait_for_suspended(), "Before opening: %s (%s)\n",
- filepath + pathinfo->base, filepath);
-
fd = open(filepath, O_RDONLY | O_NONBLOCK);
if (fd < 0) {
igt_debug("Failed to open '%s': %m\n", filepath);
--
2.25.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* RE: Kernel 5.5.4 build fail for BPF-selftests with latest LLVM
From: Bird, Tim @ 2020-02-20 17:41 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jesper Dangaard Brouer, shuah, Daniel Díaz, Andrii Nakryiko,
Andrii Nakryiko, netdev@vger.kernel.org, BPF-dev-list,
Daniel Borkmann, David Miller, LKML, Greg Kroah-Hartman,
Anders Roxell, Toke Høiland-Jørgensen,
open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <20200220172612.7aqmiwrnizgsukvm@ast-mbp>
> -----Original Message-----
> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>
> On Thu, Feb 20, 2020 at 05:02:25PM +0000, Bird, Tim wrote:
> >
> > > -----Original Message-----
> > > From: Jesper Dangaard Brouer
> > >
> > > On Wed, 19 Feb 2020 17:47:23 -0700
> > > shuah <shuah@kernel.org> wrote:
> > >
> > > > On 2/19/20 5:27 PM, Alexei Starovoitov wrote:
> > > > > On Wed, Feb 19, 2020 at 03:59:41PM -0600, Daniel Díaz wrote:
> > > > >>>
> > > > >>> When I download a specific kernel release, how can I know what LLVM
> > > > >>> git-hash or version I need (to use BPF-selftests)?
> > > > >
> > > > > as discussed we're going to add documentation-like file that will
> > > > > list required commits in tools.
> > > > > This will be enforced for future llvm/pahole commits.
> > > > >
> > > > >>> Do you think it is reasonable to require end-users to compile their own
> > > > >>> bleeding edge version of LLVM, to use BPF-selftests?
> > > > >
> > > > > absolutely.
> >
> > Is it just the BPF-selftests that require the bleeding edge version of LLVM,
> > or do BPF features themselves need the latest LLVM. If the latter, then this
> > is quite worrisome, and I fear the BPF developers are getting ahead of themselves.
> > We don't usually have a kernel dependency on the latest compiler version (some
> > recent security fixes are an anomaly). In fact deprecating support for older compiler
> > versions has been quite slow and methodical over the years.
> >
> > It's quite dangerous to be baking stuff into the kernel that depends on features
> > from compilers that haven't even made it to release yet.
> >
> > I'm sorry, but I'm coming into the middle of this thread. Can you please explain
> > what the features are in the latest LLVM that are required for BPF-selftests?
>
> Above is correct. bpf kernel features do depend on the latest pahole and llvm
> features that did not make it into a release. That was the case for many years
> now and still the case. The first commit 8 years ago relied on something that
> can generate those instructions. For many years llvm was the only compiler that
> could generate them. Right now there is GCC backend as well. New features (like
> new instructions) depend on the compiler.
>
> selftests/bpf are not testing kernel's bpf features. They are testing the whole
> bpf ecosystem. They test llvm, pahole, libbpf, bpftool, and kernel together.
> Hence it's a requirement to install the latest pahole and llvm.
>
> When I'm talking about selftests/bpf I'm talking about all the tests in that
> directory combined. There are several unit tests scattered across repos. The
> unit tests for llvm bpf backend are inside llvm repo.
> selftests/bpf/test_verifier and test_maps are unit tests for the verifier and
> for maps. They are llvm independent. They test a combination of kernel and
> libbpf only. But majority of the selftests/bpf are done via test_progs which
> are the whole ecosystem tests.
Alexei,
Thank you very much for this explanation. It is very helpful. I apologize for my
ignorance of this, but can I ask a few questions just to check my understanding?
Please forgive me if I use the wrong terminology below.
So - do the BPF developers add new instructions to the virtual machine, that then
have to be added to both the compiler and the executor (VM implementation)?
It sounds like the compiler support and executor support is done in concert, and
that patches are at least accepted upstream (but possibly are not yet available in
a compiler release) for the compiler side. What about the Linux kernel side? Is the
support for a new instruction only in non-released kernels (say, in the BPF development
tree), or could it potentially be included in a released kernel, before the compiler
with matching support is released? What would happen if a bug was found, and
compiler support for the instruction was delayed? I suppose that this would only
mean that the executor supported an instruction that never appeared in a compiled
BPF program? Is that right?
Thanks,
-- Tim
^ permalink raw reply
* Re: [PATCH v3] nvme-fabrics: reject I/O to offline device
From: James Smart @ 2020-02-20 17:41 UTC (permalink / raw)
To: Sagi Grimberg, Christoph Hellwig, Victor Gladkov
Cc: linux-nvme@lists.infradead.org, Mike Snitzer, Hannes Reinecke
In-Reply-To: <7ac74c23-db96-56e0-ad6e-24bb4df1934b@grimberg.me>
On 2/20/2020 12:34 AM, Sagi Grimberg wrote:
>
>>> +static void nvme_failfast_work(struct work_struct *work)
>>> +{
>>> + struct nvme_ctrl *ctrl = container_of(to_delayed_work(work),
>>> + struct nvme_ctrl, failfast_work);
>>> +
>>> + spin_lock_irq(&ctrl->lock);
>>> + if (ctrl->state == NVME_CTRL_CONNECTING) {
>>> + set_bit(NVME_CTRL_FAILFAST_EXPIRED, &ctrl->flags);
>>> + dev_info(ctrl->device, "failfast expired set for controller
>>> %s\n", ctrl->opts->subsysnqn);
>>
>> Please break up the line.
>>
>> But looking at the use of NVME_CTRL_FAILFAST_EXPIRED, it almost seems
>> like this is another controller state?
>
> It actually is a controller state. this is just adding another state
> without really fitting it into the state machine. I'd personally
> would want that to happen, but I know James had some rejects on
> this.
I don't believe its a controller state - rather an attribute, relative
to within the Connecting state (which may be in the process of
retrying), where instead of busying any io request that may be received,
we start to fail them. I don't see this time window as something the
controller has to actually transition through - meaning we aren't
reconnecting while in this state.
>
> Also, I still say that its default changes the existing behavior which
> is something we want to avoid.
I thought the last patch was the same as existing behavior (e.g. default
tmo is 0, and if 0, the timer, which sets the now-fail flag, never gets
scheduled).
in the last review, I was exploring the option if we did want to change
the default, as the default is a rather long wait (I did vacilate). But
I'm fine with keeping things the same.
-- james
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t] intel-ci: add a pre-merge blacklist to reduce the testing queue
From: Chris Wilson @ 2020-02-20 17:41 UTC (permalink / raw)
To: Martin Peres, igt-dev
In-Reply-To: <158221338920.8112.6424522736784766890@skylake-alporthouse-com>
Quoting Chris Wilson (2020-02-20 15:43:09)
> Quoting Martin Peres (2020-02-20 15:32:09)
> > +###############################################################################
> > +# This test is reading one file at a time while being suspended, which makes
> > +# testing extremelly slow. This is somewhat of an edge case that is unlikely
> > +# to be hit, hence why it could be dropped from pre-merge testing. Here are the
> > +# execution time statistics:
> > +#
> > +# - shard-skl: 0.5% (~1 minute)
> > +# - shard-kbl: 0.1% (~2 seconds)
> > +# - shard-apl: 0.1% (~2 seconds)
> > +# - shard-glk: 0.1% (~2 seconds)
> > +# - shard-icl: 0.6% (~1.5 minutes)
> > +# - shard-tgl: 0.7% (~1.5 minutes)
> > +#
> > +# Data acquired on 2020-02-20 by Martin Peres
> > +###############################################################################
> > +igt@i915_pm_rpm@debugfs-read
>
> You can say the debugfs-read is a developer-only feature, and it is the
> sysfs-read that must be kept working. However, the danger here is that
> we get random errors in other tests that would have been caught by this.
Actually, a 60x difference between systems => bug.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v2 0/6] NFS: Add support for the v4.2 READ_PLUS operation
From: Chuck Lever @ 2020-02-20 17:40 UTC (permalink / raw)
To: Anna Schumaker; +Cc: Trond.Myklebust, Linux NFS Mailing List, Anna Schumaker
In-Reply-To: <20200214211227.407836-1-Anna.Schumaker@Netapp.com>
Hi Anna-
> On Feb 14, 2020, at 4:12 PM, schumaker.anna@gmail.com wrote:
>
> From: Anna Schumaker <Anna.Schumaker@Netapp.com>
>
> These patches add client support for the READ_PLUS operation, which
> breaks read requests into several "data" and "hole" segments when
> replying to the client. I also add a "noreadplus" mount option to allow
> users to disable the new operation if it becomes a problem, similar to
> the "nordirplus" mount option that we already have.
Hrm, I went looking for the patch that adds "noreadplus", but I
don't see it in this series?
Wondering if, to start off, the default should be "noreadplus"
until our feet are under us. Just a thought.
> Here are the results of some performance tests I ran on Netapp lab
> machines. I tested by reading various 2G files from a few different
> undelying filesystems and across several NFS versions. I used the
> `vmtouch` utility to make sure files were only cached when we wanted
> them to be. In addition to 100% data and 100% hole cases, I also tested
> with files that alternate between data and hole segments. These files
> have either 4K, 8K, 16K, or 32K segment sizes and start with either data
> or hole segments. So the file mixed-4d has a 4K segment size beginning
> with a data segment, but mixed-32h hase 32K segments beginning with a
> hole. The units are in seconds, with the first number for each NFS
> version being the uncached read time and the second number is for when
> the file is cached on the server.
>
> ext4 | v3 | v4.0 | v4.1 | v4.2 |
> ----------|-----------------|-----------------|-----------------|-----------------|
> data | 22.909 : 18.253 | 22.934 : 18.252 | 22.902 : 18.253 | 23.485 : 18.253 |
> hole | 18.256 : 18.253 | 18.255 : 18.252 | 18.256 : 18.253 | 0.708 : 0.709 |
> mixed-4d | 28.261 : 18.253 | 29.616 : 18.252 | 28.341 : 18.252 | 24.508 : 9.150 |
> mixed-8d | 27.956 : 18.253 | 28.404 : 18.252 | 28.320 : 18.252 | 23.967 : 9.140 |
> mixed-16d | 28.172 : 18.253 | 27.946 : 18.252 | 27.627 : 18.252 | 23.043 : 9.134 |
> mixed-32d | 25.350 : 18.253 | 24.406 : 18.252 | 24.384 : 18.253 | 20.698 : 9.132 |
> mixed-4h | 28.913 : 18.253 | 28.564 : 18.252 | 27.996 : 18.252 | 21.837 : 9.150 |
> mixed-8h | 28.625 : 18.253 | 27.833 : 18.252 | 27.798 : 18.253 | 21.710 : 9.140 |
> mixed-16h | 27.975 : 18.253 | 27.662 : 18.252 | 27.795 : 18.253 | 20.585 : 9.134 |
> mixed-32h | 25.958 : 18.253 | 25.491 : 18.252 | 24.856 : 18.252 | 21.018 : 9.132 |
>
> xfs | v3 | v4.0 | v4.1 | v4.2 |
> ----------|-----------------|-----------------|-----------------|-----------------|
> data | 22.041 : 18.253 | 22.618 : 18.252 | 23.067 : 18.253 | 23.496 : 18.253 |
> hole | 18.256 : 18.253 | 18.255 : 18.252 | 18.256 : 18.253 | 0.723 : 0.708 |
> mixed-4d | 29.417 : 18.253 | 28.503 : 18.252 | 28.671 : 18.253 | 24.957 : 9.150 |
> mixed-8d | 29.080 : 18.253 | 29.401 : 18.252 | 29.251 : 18.252 | 24.625 : 9.140 |
> mixed-16d | 27.638 : 18.253 | 28.606 : 18.252 | 27.871 : 18.253 | 25.511 : 9.135 |
> mixed-32d | 24.967 : 18.253 | 25.239 : 18.252 | 25.434 : 18.252 | 21.728 : 9.132 |
> mixed-4h | 34.816 : 18.253 | 36.243 : 18.252 | 35.837 : 18.252 | 32.332 : 9.150 |
> mixed-8h | 43.469 : 18.253 | 44.009 : 18.252 | 43.810 : 18.253 | 37.962 : 9.140 |
> mixed-16h | 29.280 : 18.253 | 28.563 : 18.252 | 28.241 : 18.252 | 22.116 : 9.134 |
> mixed-32h | 29.428 : 18.253 | 29.378 : 18.252 | 28.808 : 18.253 | 27.378 : 9.134 |
>
> btrfs | v3 | v4.0 | v4.1 | v4.2 |
> ----------|-----------------|-----------------|-----------------|-----------------|
> data | 25.547 : 18.253 | 25.053 : 18.252 | 24.209 : 18.253 | 32.121 : 18.253 |
> hole | 18.256 : 18.253 | 18.255 : 18.252 | 18.256 : 18.252 | 0.702 : 0.724 |
> mixed-4d | 19.016 : 18.253 | 18.822 : 18.252 | 18.955 : 18.253 | 18.697 : 9.150 |
> mixed-8d | 19.186 : 18.253 | 19.444 : 18.252 | 18.841 : 18.253 | 18.452 : 9.140 |
> mixed-16d | 18.480 : 18.253 | 19.010 : 18.252 | 19.167 : 18.252 | 16.000 : 9.134 |
> mixed-32d | 18.635 : 18.253 | 18.565 : 18.252 | 18.550 : 18.252 | 15.930 : 9.132 |
> mixed-4h | 19.079 : 18.253 | 18.990 : 18.252 | 19.157 : 18.253 | 27.834 : 9.150 |
> mixed-8h | 18.613 : 18.253 | 19.234 : 18.252 | 18.616 : 18.253 | 20.177 : 9.140 |
> mixed-16h | 18.590 : 18.253 | 19.221 : 18.252 | 19.654 : 18.253 | 17.273 : 9.135 |
> mixed-32h | 18.768 : 18.253 | 19.122 : 18.252 | 18.535 : 18.252 | 15.791 : 9.132 |
>
> ext3 | v3 | v4.0 | v4.1 | v4.2 |
> ----------|-----------------|-----------------|-----------------|-----------------|
> data | 34.292 : 18.253 | 33.810 : 18.252 | 33.450 : 18.253 | 33.390 : 18.254 |
> hole | 18.256 : 18.253 | 18.255 : 18.252 | 18.256 : 18.253 | 0.718 : 0.728 |
> mixed-4d | 46.818 : 18.253 | 47.140 : 18.252 | 48.385 : 18.253 | 42.887 : 9.150 |
> mixed-8d | 58.554 : 18.253 | 59.277 : 18.252 | 59.673 : 18.253 | 56.760 : 9.140 |
> mixed-16d | 44.631 : 18.253 | 44.291 : 18.252 | 44.729 : 18.253 | 40.237 : 9.135 |
> mixed-32d | 39.110 : 18.253 | 38.735 : 18.252 | 38.902 : 18.252 | 35.270 : 9.132 |
> mixed-4h | 56.396 : 18.253 | 56.387 : 18.252 | 56.573 : 18.253 | 67.661 : 9.150 |
> mixed-8h | 58.483 : 18.253 | 58.484 : 18.252 | 59.099 : 18.253 | 77.958 : 9.140 |
> mixed-16h | 42.511 : 18.253 | 42.338 : 18.252 | 42.356 : 18.252 | 51.805 : 9.135 |
> mixed-32h | 38.419 : 18.253 | 38.504 : 18.252 | 38.643 : 18.252 | 40.411 : 9.132 |
>
>
> Changes since v1:
> - Rebase to 5.6-rc1
> - Drop the mount option patch for now
> - Fix fallback to READ when the server doesn't support READ_PLUS
>
> Any questions?
> Anna
>
>
> Anna Schumaker (6):
> SUNRPC: Split out a function for setting current page
> SUNRPC: Add the ability to expand holes in data pages
> SUNRPC: Add the ability to shift data to a specific offset
> NFS: Add READ_PLUS data segment support
> NFS: Add READ_PLUS hole segment decoding
> NFS: Decode multiple READ_PLUS segments
>
> fs/nfs/nfs42xdr.c | 169 +++++++++++++++++++++++++
> fs/nfs/nfs4proc.c | 43 ++++++-
> fs/nfs/nfs4xdr.c | 1 +
> include/linux/nfs4.h | 2 +-
> include/linux/nfs_fs_sb.h | 1 +
> include/linux/nfs_xdr.h | 2 +-
> include/linux/sunrpc/xdr.h | 2 +
> net/sunrpc/xdr.c | 244 ++++++++++++++++++++++++++++++++++++-
> 8 files changed, 457 insertions(+), 7 deletions(-)
>
> --
> 2.25.0
>
--
Chuck Lever
chucklever@gmail.com
^ permalink raw reply
* uxfs review
From: Valentin Vidić @ 2020-02-20 17:39 UTC (permalink / raw)
To: kernelnewbies
On Wed, Feb 19, 2020 at 04:36:10PM -0500, Valdis Klētnieks wrote:
> (Of course, if you're trying to get a 2.6.12 driver working on 5.6... you may decide
> that it's time to start drinking heavily :)
Now that you mention 2.6 :), I've been trying to update this uxfs
filesystem from an old book[1] for modern kernels:
https://github.com/vvidic/uxfs/
It currently builds and seems to work but it could probably use a
review if someone has a bit of time? I can post the diff here if
that would be easier.
[1] Steve D. Pate, UNIX Filesystems, 2003.
--
Valentin
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply
* Re: Questions about logic_pio
From: John Garry @ 2020-02-20 17:39 UTC (permalink / raw)
To: Jiaxun Yang
Cc: xuwei (O), bhelgaas, andyshevchenko, Arnd Bergmann, linux-kernel,
Linux Mips
In-Reply-To: <170632822e1.12fede49a6919.5706082545515934736@flygoat.com>
On 20/02/2020 15:12, Jiaxun Yang wrote:
>
> ---- 在 星期四, 2020-02-20 22:23:57 John Garry <john.garry@huawei.com> 撰写 ----
> > > Also Cc MIPS list to check other's opinions.
> > >
> > > Hi John.
> > >
> >
> > Hi Jiaxun Yang,
> >
> > > Thanks for your kind explanation, however, I think this way is
> > > violating how I/O ports supposed to work, at least in MIPS world.
> >
> > For a bit more history, please understand that the core PCI code was
> > managing non-native IO port space in the same way before we added the
> > logic PIO framework. The only real functional change here was that we
> > introduced the indirect-io region within the IO port space, under
> > CONFIG_INDIRECT_PIO.
>
> I'm going to do more investigation. Thanks.
>
> >
> > >
> > > > >>
> > > > >> After dig into logic pio logic, I found that logic pio is trying to "allocate" an io_start
> > > > >> for MMIO ranges, the allocation starts from 0x0. And later the io_start is used to calculate
> > > > >> cpu_address. In my opinion, for direct MMIO access, logic_pio address should always
> > > > >> equal to hw address,
> > > >
> > > > I'm not sure what you mean by simply the hw address.
> > > >
> > >
> > > I meant hw_start should always equal to io_start.
> > >
> > >
> > > MIPS have their own wrapped inl/outl functions,
> >
> > Can you please point me to these? I could not find them in arch/mips
>
> They are built by __BUILD_IOPORT_PFX(bus, bwlq, type) macro.
> Just using mips_io_port_base + offset to handle inl/outl, the same way PCI_IOBASE.
Right, so I had a glance through the code and mips has it own management
of this IO port space. And, like you say, mips_io_port_base is
equivalent to PCI_IOBASE.
>
> >
> > I will also note that arch/mips/include/asm/io.h does not include
> > asm-generic io.h today
>
> Yes, and I'm attempting to take advantage of asm-generic.
I just don't think it's as simple as saying we want to take advantage of
asm-generic. asm-generic io.h includes logic_pio.h, which uses logical
PIO to manage IO port space and relies on PIO_IOBASE. This is
incompatible with having some other framework - like mips_io_port_base -
managing IO port space at the same time.
The core PCI code relies on logical PIO to manage IO port space for when
PCI_IOBASE is defined.
>
> >
> > doing the samething with
> > > PCI_IOBASE enabled one. I was just trying to use PCI_IOBASE instead.
> > >
> > > Originally, the I/O ports layout seems like this:
> > >
> > > 00000020-00000021 : pic1
> > > 00000060-0000006f : i8042
> > > 00000070-00000077 : rtc0
> > > 000000a0-000000a1 : pic2
> > > 00000170-00000177 : pata_atiixp
> > > 000001f0-000001f7 : pata_atiixp
> > > 00000376-00000376 : pata_atiixp
> > > 000003f6-000003f6 : pata_atiixp
> > > 00000800-000008ff : acpi
> > > 00001000-00001008 : piix4_smbus
> > > 00004000-0003ffff : pci io space
> > > 00004000-00004fff : PCI Bus 0000:01
> > > 00004000-000040ff : 0000:01:05.0
> > > 00005000-00005fff : PCI Bus 0000:03
> > > 00005000-0000501f : 0000:03:00.0
> > >
> > > But with PCI_IOBASE defined, I got this:
> > >
> > > host bridge /bus@10000000/pci@10000000 ranges:
> > > MEM 0x0040000000..0x007fffffff -> 0x0040000000
> > > IO 0x0000004000..0x0000007fff -> 0x0000004000
> > > resource collision: [io 0x0000-0x3fff] conflicts with pic1 [io 0x0020-0x0021]
> > >
> > > Because io_start was allocated to 0x0 by Logic PIO.
> > >
> > > There are a lot of devices that have fixed ioports thanks to x86's legacy.
> >
> > Well, yes, I'm not so surprised.
> >
> > So if MIPS does not have native IO port access, then surely you need
> > some host bridge to translate host CPU MMIO accesses to port I/O
> > accesses, right? Where are these CPU addresses defined?
>
> It is defined by the variable mips_io_port_base.
>
> >
> > > For example, in my hardware, ioports for RTC, PIC, I8042 are unmoveable,
> > > and they can't be managed by logic pio subsystem. > Also, the PCI Hostbridge got implied by DeviceTree that it's I/O range
> > > started from 0x4000 in bus side
> >
> > which bus is this?
>
> They're all located under "ISA Range". Just an MMIO range that will resend
> the request to ISA I/O. --ioports for both PCI and some legacy devices.
>
> In that range, base + 0x0000 to 0x4000 is preserved for PIO devices (e.g.) I8259
> and base + 0x4000 to MMIO_LIMIT are for PCI devices under host bridge.
> For the host bridge, ioports it can decode starts from 0x4000.
>
> My intentional behavior is that when I'm specifying in dts that the IO Range of PCI host
> bridge is 0x4000 to 0x7fff, it would request the IO_RESOURCE start from 0x4000
> to 0x7fff, also tell the host driver to decode 0x4000 to 0x7fff in IO BAR, And let the drivers
> access 0x4000 to 0x7fff via inl/outl, rather than allocate from PIO 0x0 to 0x3fff.
>
> >
> > , but then, Logic PIO remapped to PCI_IOBASE + 0x0.
> > > The real address should be PCI_IOBASE + 0x4000,
> >
> > You seem to be using two methods to manage IO port space, and they seem
> > to be conflicting.
>
> So... Are there any way to handle these unmoveable devices in logic pio world?
When you say that they are unmovable, they are at a fixed address on
this "ISA Range", right? If so, yes, you should be able to handle it in
logical PIO. You just need to deal with translating logical PIO
addresses to ISA bus addresses. We do this very thing in our LPC driver
- see drivers/bus/hisi_lpc.c
This driver deals with legacy IO ports where we need to bitbang
accesses, i.e. we don't support MMIO for this.
>
> >
> > > hardware never got correctly informed about that. And there is still no way to
> > > transform to correct address as it's inside the MMIO_LIMIT.
> > >
> > > So the question comes to why we're allocating io_start for MMIO PCI_IOBASE
> > > rather than just check the range provided doesn't overlap each other or exceed
> > > the MMIO_LIMIT.
> >
> > When PCI_IOBASE is defined, we work on the basis that any IO port range
> > in the system is registered for a logical PIO region, which manages the
> > actual IO port addresses - see logic_pio_trans_cpuaddr().
>
> The port is not the actual port.. It makes me confusing about what it's actually doing..
> Sorry but probably I'm still thinking in a vintage way -- need some hints about how to
> deal with these legacy cases in a modern way.
>
> Thanks.
>
> >
> > Thanks,
> > John
> >
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.