* [PATCH 06/11] PCI: of: Add inbound resource parsing to helpers
From: Rob Herring @ 2019-09-24 21:46 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Lorenzo Pieralisi
Cc: Heiko Stuebner, Karthikeyan Mitran, Linus Walleij,
Thomas Petazzoni, Toan Le, Will Deacon, Ryder Lee, Michal Simek,
linux-rockchip, bcm-kernel-feedback-list, Shawn Lin, Ray Jui,
Hou Zhiqiang, Simon Horman, linux-mediatek, linux-arm-kernel,
Scott Branden, Jingoo Han, rfi, linux-renesas-soc, Tom Joseph,
Gustavo Pimentel, Ley Foon Tan
In-Reply-To: <20190924214630.12817-1-robh@kernel.org>
Extend devm_of_pci_get_host_bridge_resources() and
pci_parse_request_of_pci_ranges() helpers to also parse the inbound
addresses from DT 'dma-ranges' and populate a resource list with the
translated addresses. This will help ensure 'dma-ranges' is always
parsed in a consistent way.
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Will Deacon <will@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Toan Le <toan@os.amperecomputing.com>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Tom Joseph <tjoseph@cadence.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Karthikeyan Mitran <m.karthikeyan@mobiveil.co.in>
Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: rfi@lists.rocketboards.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
.../pci/controller/dwc/pcie-designware-host.c | 3 +-
drivers/pci/controller/pci-aardvark.c | 2 +-
drivers/pci/controller/pci-ftpci100.c | 3 +-
drivers/pci/controller/pci-host-common.c | 2 +-
drivers/pci/controller/pci-v3-semi.c | 2 +-
drivers/pci/controller/pci-versatile.c | 2 +-
drivers/pci/controller/pci-xgene.c | 1 +
drivers/pci/controller/pcie-altera.c | 2 +-
drivers/pci/controller/pcie-cadence-host.c | 2 +-
drivers/pci/controller/pcie-iproc-platform.c | 1 +
drivers/pci/controller/pcie-mediatek.c | 2 +-
drivers/pci/controller/pcie-mobiveil.c | 4 +-
drivers/pci/controller/pcie-rcar.c | 3 +-
drivers/pci/controller/pcie-rockchip-host.c | 3 +-
drivers/pci/controller/pcie-xilinx-nwl.c | 2 +-
drivers/pci/controller/pcie-xilinx.c | 2 +-
drivers/pci/of.c | 44 ++++++++++++++++++-
drivers/pci/pci.h | 8 +++-
include/linux/pci.h | 2 +
19 files changed, 72 insertions(+), 18 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index f93252d0da5b..0743ae64bb0f 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -342,7 +342,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
return -ENOMEM;
ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
- &bridge->windows, &pp->io_base);
+ &bridge->windows, &bridge->dma_ranges,
+ &pp->io_base);
if (ret)
return ret;
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index ff3af3d34028..c00b391529f3 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -940,7 +940,7 @@ static int advk_pcie_probe(struct platform_device *pdev)
}
ret = pci_parse_request_of_pci_ranges(dev, &pcie->resources,
- &bus);
+ &bridge->dma_ranges, &bus);
if (ret) {
dev_err(dev, "Failed to parse resources\n");
return ret;
diff --git a/drivers/pci/controller/pci-ftpci100.c b/drivers/pci/controller/pci-ftpci100.c
index bf5ece5d9291..3e07a8203736 100644
--- a/drivers/pci/controller/pci-ftpci100.c
+++ b/drivers/pci/controller/pci-ftpci100.c
@@ -481,7 +481,8 @@ static int faraday_pci_probe(struct platform_device *pdev)
return PTR_ERR(p->base);
ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
- &res, &io_base);
+ &res, &host->dma_ranges,
+ &io_base);
if (ret)
return ret;
diff --git a/drivers/pci/controller/pci-host-common.c b/drivers/pci/controller/pci-host-common.c
index c742881b5061..183381c19ee8 100644
--- a/drivers/pci/controller/pci-host-common.c
+++ b/drivers/pci/controller/pci-host-common.c
@@ -27,7 +27,7 @@ static struct pci_config_window *gen_pci_init(struct device *dev,
struct pci_config_window *cfg;
/* Parse our PCI ranges and request their resources */
- err = pci_parse_request_of_pci_ranges(dev, resources, &bus_range);
+ err = pci_parse_request_of_pci_ranges(dev, resources, NULL, &bus_range);
if (err)
return ERR_PTR(err);
diff --git a/drivers/pci/controller/pci-v3-semi.c b/drivers/pci/controller/pci-v3-semi.c
index d219404bad92..090df766faf9 100644
--- a/drivers/pci/controller/pci-v3-semi.c
+++ b/drivers/pci/controller/pci-v3-semi.c
@@ -794,7 +794,7 @@ static int v3_pci_probe(struct platform_device *pdev)
return PTR_ERR(v3->config_base);
ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
- &io_base);
+ &host->dma_ranges, &io_base);
if (ret)
return ret;
diff --git a/drivers/pci/controller/pci-versatile.c b/drivers/pci/controller/pci-versatile.c
index 237b1abb26f2..211159f54b4a 100644
--- a/drivers/pci/controller/pci-versatile.c
+++ b/drivers/pci/controller/pci-versatile.c
@@ -93,7 +93,7 @@ static int versatile_pci_probe(struct platform_device *pdev)
if (IS_ERR(versatile_cfg_base[1]))
return PTR_ERR(versatile_cfg_base[1]);
- ret = pci_parse_request_of_pci_ranges(dev, &pci_res, NULL);
+ ret = pci_parse_request_of_pci_ranges(dev, &pci_res, NULL, NULL);
if (ret)
return ret;
diff --git a/drivers/pci/controller/pci-xgene.c b/drivers/pci/controller/pci-xgene.c
index ffda3e8b4742..11f27c42c06a 100644
--- a/drivers/pci/controller/pci-xgene.c
+++ b/drivers/pci/controller/pci-xgene.c
@@ -635,6 +635,7 @@ static int xgene_pcie_probe(struct platform_device *pdev)
return ret;
ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ &bridge->dma_ranges,
&iobase);
if (ret)
return ret;
diff --git a/drivers/pci/controller/pcie-altera.c b/drivers/pci/controller/pcie-altera.c
index 2ed00babff5a..fde6a3b16fb9 100644
--- a/drivers/pci/controller/pcie-altera.c
+++ b/drivers/pci/controller/pcie-altera.c
@@ -801,7 +801,7 @@ static int altera_pcie_probe(struct platform_device *pdev)
}
ret = pci_parse_request_of_pci_ranges(dev, &pcie->resources,
- NULL);
+ &bridge->dma_ranges, NULL);
if (ret) {
dev_err(dev, "Failed add resources\n");
return ret;
diff --git a/drivers/pci/controller/pcie-cadence-host.c b/drivers/pci/controller/pcie-cadence-host.c
index 97e251090b4f..a8f7a6284c3e 100644
--- a/drivers/pci/controller/pcie-cadence-host.c
+++ b/drivers/pci/controller/pcie-cadence-host.c
@@ -211,7 +211,7 @@ static int cdns_pcie_host_init(struct device *dev,
int err;
/* Parse our PCI ranges and request their resources */
- err = pci_parse_request_of_pci_ranges(dev, resources, &bus_range);
+ err = pci_parse_request_of_pci_ranges(dev, resources, NULL, &bus_range);
if (err)
return err;
diff --git a/drivers/pci/controller/pcie-iproc-platform.c b/drivers/pci/controller/pcie-iproc-platform.c
index 5a3550b6bb29..62eee2d17f43 100644
--- a/drivers/pci/controller/pcie-iproc-platform.c
+++ b/drivers/pci/controller/pcie-iproc-platform.c
@@ -101,6 +101,7 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev)
}
ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &resources,
+ &bridge->dma_ranges,
&iobase);
if (ret) {
dev_err(dev, "unable to get PCI host bridge resources\n");
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index cea4112b5309..f3996eed152d 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -1032,7 +1032,7 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
int err;
err = pci_parse_request_of_pci_ranges(dev, windows,
- &bus);
+ &host->dma_ranges, &bus);
if (err)
return err;
diff --git a/drivers/pci/controller/pcie-mobiveil.c b/drivers/pci/controller/pcie-mobiveil.c
index 672e633601c7..93064faaa656 100644
--- a/drivers/pci/controller/pcie-mobiveil.c
+++ b/drivers/pci/controller/pcie-mobiveil.c
@@ -875,7 +875,9 @@ static int mobiveil_pcie_probe(struct platform_device *pdev)
/* parse the host bridge base addresses from the device tree file */
ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
- &pcie->resources, &iobase);
+ &pcie->resources,
+ &bridge->dma_ranges,
+ &iobase);
if (ret) {
dev_err(dev, "Getting bridge resources failed\n");
return ret;
diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
index f6a669a9af41..b8d6e86a5539 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -1138,7 +1138,8 @@ static int rcar_pcie_probe(struct platform_device *pdev)
pcie->dev = dev;
platform_set_drvdata(pdev, pcie);
- err = pci_parse_request_of_pci_ranges(dev, &pcie->resources, NULL);
+ err = pci_parse_request_of_pci_ranges(dev, &pcie->resources,
+ &bridge->dma_ranges, NULL);
if (err)
goto err_free_bridge;
diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index 8d20f1793a61..093b816b9dc9 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -996,7 +996,8 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
goto err_deinit_port;
err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
- &res, &io_base);
+ &res, &bridge->dma_ranges,
+ &io_base);
if (err)
goto err_remove_irq_domain;
diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c
index 45c0f344ccd1..5c9132a02d15 100644
--- a/drivers/pci/controller/pcie-xilinx-nwl.c
+++ b/drivers/pci/controller/pcie-xilinx-nwl.c
@@ -846,7 +846,7 @@ static int nwl_pcie_probe(struct platform_device *pdev)
}
err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
- &iobase);
+ &bridge->dma_ranges, &iobase);
if (err) {
dev_err(dev, "Getting bridge resources failed\n");
return err;
diff --git a/drivers/pci/controller/pcie-xilinx.c b/drivers/pci/controller/pcie-xilinx.c
index 5bf3af3b28e6..a95faca30291 100644
--- a/drivers/pci/controller/pcie-xilinx.c
+++ b/drivers/pci/controller/pcie-xilinx.c
@@ -648,7 +648,7 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
}
err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
- &iobase);
+ &bridge->dma_ranges, &iobase);
if (err) {
dev_err(dev, "Getting bridge resources failed\n");
return err;
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index bc7b27a28795..8d31e078461f 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -257,7 +257,9 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
*/
int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
- struct list_head *resources, resource_size_t *io_base)
+ struct list_head *resources,
+ struct list_head *ib_resources,
+ resource_size_t *io_base)
{
struct device_node *dev_node = dev->of_node;
struct resource *res, tmp_res;
@@ -340,6 +342,42 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev,
pci_add_resource_offset(resources, res, res->start - range.pci_addr);
}
+ /* Check for dma-ranges property */
+ if (!ib_resources)
+ return 0;
+ err = of_pci_dma_range_parser_init(&parser, dev_node);
+ if (err)
+ return 0;
+
+ dev_dbg(dev, "Parsing dma-ranges property...\n");
+ for_each_of_pci_range(&parser, &range) {
+ /*
+ * If we failed translation or got a zero-sized region
+ * then skip this range
+ */
+ if (((range.flags & IORESOURCE_TYPE_BITS) != IORESOURCE_MEM) ||
+ range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+ continue;
+
+ dev_info(dev, "IB MEM %#010llx..%#010llx -> %#010llx\n",
+ range.cpu_addr,
+ range.cpu_addr + range.size - 1, range.pci_addr);
+
+
+ err = of_pci_range_to_resource(&range, dev_node, &tmp_res);
+ if (err)
+ continue;
+
+ res = devm_kmemdup(dev, &tmp_res, sizeof(tmp_res), GFP_KERNEL);
+ if (!res) {
+ err = -ENOMEM;
+ goto failed;
+ }
+
+ pci_add_resource_offset(ib_resources, res,
+ res->start - range.pci_addr);
+ }
+
return 0;
failed:
@@ -482,6 +520,7 @@ EXPORT_SYMBOL_GPL(of_irq_parse_and_map_pci);
int pci_parse_request_of_pci_ranges(struct device *dev,
struct list_head *resources,
+ struct list_head *ib_resources,
struct resource **bus_range)
{
int err, res_valid = 0;
@@ -489,8 +528,9 @@ int pci_parse_request_of_pci_ranges(struct device *dev,
struct resource_entry *win, *tmp;
INIT_LIST_HEAD(resources);
+ INIT_LIST_HEAD(ib_resources);
err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, resources,
- &iobase);
+ ib_resources, &iobase);
if (err)
return err;
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index d22d1b807701..790458953c54 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -582,11 +582,15 @@ of_pci_get_max_link_speed(struct device_node *node)
#if defined(CONFIG_OF_ADDRESS)
int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
- struct list_head *resources, resource_size_t *io_base);
+ struct list_head *resources,
+ struct list_head *ib_resources,
+ resource_size_t *io_base);
#else
static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
- struct list_head *resources, resource_size_t *io_base)
+ struct list_head *resources,
+ struct list_head *ib_resources,
+ resource_size_t *io_base);
{
return -EINVAL;
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 82e4cd1b7ac3..d57389b86f92 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2312,6 +2312,7 @@ void pci_release_bus_of_node(struct pci_bus *bus);
struct irq_domain *pci_host_bridge_of_msi_domain(struct pci_bus *bus);
int pci_parse_request_of_pci_ranges(struct device *dev,
struct list_head *resources,
+ struct list_head *ib_resources,
struct resource **bus_range);
/* Arch may override this (weak) */
@@ -2326,6 +2327,7 @@ static inline struct irq_domain *
pci_host_bridge_of_msi_domain(struct pci_bus *bus) { return NULL; }
static inline int pci_parse_request_of_pci_ranges(struct device *dev,
struct list_head *resources,
+ struct list_head *ib_resources,
struct resource **bus_range)
{
return -EINVAL;
--
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 07/11] PCI: ftpci100: Use inbound resources for setup
From: Rob Herring @ 2019-09-24 21:46 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Lorenzo Pieralisi; +Cc: linux-arm-kernel
In-Reply-To: <20190924214630.12817-1-robh@kernel.org>
Now that the helpers provide the inbound resources in the host bridge
'dma_ranges' resource list, convert Faraday ftpci100 host bridge to use
the resource list to setup the inbound addresses.
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/pci/controller/pci-ftpci100.c | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/controller/pci-ftpci100.c b/drivers/pci/controller/pci-ftpci100.c
index 3e07a8203736..e37a33ad77d9 100644
--- a/drivers/pci/controller/pci-ftpci100.c
+++ b/drivers/pci/controller/pci-ftpci100.c
@@ -375,12 +375,11 @@ static int faraday_pci_setup_cascaded_irq(struct faraday_pci *p)
return 0;
}
-static int faraday_pci_parse_map_dma_ranges(struct faraday_pci *p,
- struct device_node *np)
+static int faraday_pci_parse_map_dma_ranges(struct faraday_pci *p)
{
- struct of_pci_range range;
- struct of_pci_range_parser parser;
struct device *dev = p->dev;
+ struct pci_host_bridge *bridge = pci_host_bridge_from_priv(p);
+ struct resource_entry *entry;
u32 confreg[3] = {
FARADAY_PCI_MEM1_BASE_SIZE,
FARADAY_PCI_MEM2_BASE_SIZE,
@@ -389,19 +388,12 @@ static int faraday_pci_parse_map_dma_ranges(struct faraday_pci *p,
int i = 0;
u32 val;
- if (of_pci_dma_range_parser_init(&parser, np)) {
- dev_err(dev, "missing dma-ranges property\n");
- return -EINVAL;
- }
-
- /*
- * Get the dma-ranges from the device tree
- */
- for_each_of_pci_range(&parser, &range) {
- u64 end = range.pci_addr + range.size - 1;
+ resource_list_for_each_entry(entry, &bridge->dma_ranges) {
+ u64 pci_addr = entry->res->start - entry->offset;
+ u64 end = entry->res->end - entry->offset;
int ret;
- ret = faraday_res_to_memcfg(range.pci_addr, range.size, &val);
+ ret = faraday_res_to_memcfg(pci_addr, resource_size(entry->res), &val);
if (ret) {
dev_err(dev,
"DMA range %d: illegal MEM resource size\n", i);
@@ -409,7 +401,7 @@ static int faraday_pci_parse_map_dma_ranges(struct faraday_pci *p,
}
dev_info(dev, "DMA MEM%d BASE: 0x%016llx -> 0x%016llx config %08x\n",
- i + 1, range.pci_addr, end, val);
+ i + 1, pci_addr, end, val);
if (i <= 2) {
faraday_raw_pci_write_config(p, 0, 0, confreg[i],
4, val);
@@ -566,7 +558,7 @@ static int faraday_pci_probe(struct platform_device *pdev)
cur_bus_speed = PCI_SPEED_66MHz;
}
- ret = faraday_pci_parse_map_dma_ranges(p, dev->of_node);
+ ret = faraday_pci_parse_map_dma_ranges(p);
if (ret)
return ret;
--
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 05/11] PCI: versatile: Use pci_parse_request_of_pci_ranges()
From: Rob Herring @ 2019-09-24 21:46 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Lorenzo Pieralisi; +Cc: linux-arm-kernel
In-Reply-To: <20190924214630.12817-1-robh@kernel.org>
Convert ARM Versatile host bridge to use the common
pci_parse_request_of_pci_ranges().
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/pci/controller/pci-versatile.c | 62 +++++---------------------
1 file changed, 11 insertions(+), 51 deletions(-)
diff --git a/drivers/pci/controller/pci-versatile.c b/drivers/pci/controller/pci-versatile.c
index f59ad2728c0b..237b1abb26f2 100644
--- a/drivers/pci/controller/pci-versatile.c
+++ b/drivers/pci/controller/pci-versatile.c
@@ -62,60 +62,12 @@ static struct pci_ops pci_versatile_ops = {
.write = pci_generic_config_write,
};
-static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
- struct list_head *res)
-{
- int err, mem = 1, res_valid = 0;
- resource_size_t iobase;
- struct resource_entry *win, *tmp;
-
- err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, res, &iobase);
- if (err)
- return err;
-
- err = devm_request_pci_bus_resources(dev, res);
- if (err)
- goto out_release_res;
-
- resource_list_for_each_entry_safe(win, tmp, res) {
- struct resource *res = win->res;
-
- switch (resource_type(res)) {
- case IORESOURCE_IO:
- err = devm_pci_remap_iospace(dev, res, iobase);
- if (err) {
- dev_warn(dev, "error %d: failed to map resource %pR\n",
- err, res);
- resource_list_destroy_entry(win);
- }
- break;
- case IORESOURCE_MEM:
- res_valid |= !(res->flags & IORESOURCE_PREFETCH);
-
- writel(res->start >> 28, PCI_IMAP(mem));
- writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
- mem++;
-
- break;
- }
- }
-
- if (res_valid)
- return 0;
-
- dev_err(dev, "non-prefetchable memory resource required\n");
- err = -EINVAL;
-
-out_release_res:
- pci_free_resource_list(res);
- return err;
-}
-
static int versatile_pci_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct resource *res;
- int ret, i, myslot = -1;
+ struct resource_entry *entry;
+ int ret, i, myslot = -1, mem = 0;
u32 val;
void __iomem *local_pci_cfg_base;
struct pci_bus *bus, *child;
@@ -141,10 +93,18 @@ static int versatile_pci_probe(struct platform_device *pdev)
if (IS_ERR(versatile_cfg_base[1]))
return PTR_ERR(versatile_cfg_base[1]);
- ret = versatile_pci_parse_request_of_pci_ranges(dev, &pci_res);
+ ret = pci_parse_request_of_pci_ranges(dev, &pci_res, NULL);
if (ret)
return ret;
+ resource_list_for_each_entry(entry, &pci_res) {
+ if (resource_type(entry->res) == IORESOURCE_MEM) {
+ writel(entry->res->start >> 28, PCI_IMAP(mem));
+ writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
+ mem++;
+ }
+ }
+
/*
* We need to discover the PCI core first to configure itself
* before the main PCI probing is performed
--
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 03/11] PCI: mediatek: Use pci_parse_request_of_pci_ranges()
From: Rob Herring @ 2019-09-24 21:46 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Lorenzo Pieralisi
Cc: Matthias Brugger, Ryder Lee, linux-mediatek, linux-arm-kernel
In-Reply-To: <20190924214630.12817-1-robh@kernel.org>
Convert Mediatek host bridge to use the common
pci_parse_request_of_pci_ranges().
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/pci/controller/pcie-mediatek.c | 47 ++++++++++----------------
1 file changed, 17 insertions(+), 30 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 80601e1b939e..cea4112b5309 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -211,7 +211,6 @@ struct mtk_pcie {
void __iomem *base;
struct clk *free_ck;
- struct resource mem;
struct list_head ports;
const struct mtk_pcie_soc *soc;
unsigned int busnr;
@@ -658,11 +657,23 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
{
struct mtk_pcie *pcie = port->pcie;
- struct resource *mem = &pcie->mem;
+ struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+ struct resource *mem = NULL;
+ struct resource_entry *entry;
const struct mtk_pcie_soc *soc = port->pcie->soc;
u32 val;
int err;
+ resource_list_for_each_entry(entry, &host->windows) {
+ if (resource_type(entry->res) != IORESOURCE_MEM)
+ continue;
+
+ mem = entry->res;
+ break;
+ }
+ if (!mem)
+ return -EINVAL;
+
/* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
if (pcie->base) {
val = readl(pcie->base + PCIE_SYS_CFG_V2);
@@ -1017,39 +1028,15 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
struct mtk_pcie_port *port, *tmp;
struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
struct list_head *windows = &host->windows;
- struct resource_entry *win, *tmp_win;
- resource_size_t io_base;
+ struct resource *bus;
int err;
- err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
- windows, &io_base);
+ err = pci_parse_request_of_pci_ranges(dev, windows,
+ &bus);
if (err)
return err;
- err = devm_request_pci_bus_resources(dev, windows);
- if (err < 0)
- return err;
-
- /* Get the I/O and memory ranges from DT */
- resource_list_for_each_entry_safe(win, tmp_win, windows) {
- switch (resource_type(win->res)) {
- case IORESOURCE_IO:
- err = devm_pci_remap_iospace(dev, win->res, io_base);
- if (err) {
- dev_warn(dev, "error %d: failed to map resource %pR\n",
- err, win->res);
- resource_list_destroy_entry(win);
- }
- break;
- case IORESOURCE_MEM:
- memcpy(&pcie->mem, win->res, sizeof(*win->res));
- pcie->mem.name = "non-prefetchable";
- break;
- case IORESOURCE_BUS:
- pcie->busnr = win->res->start;
- break;
- }
- }
+ pcie->busnr = bus->start;
for_each_available_child_of_node(node, child) {
int slot;
--
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 04/11] PCI: versatile: Enable COMPILE_TEST
From: Rob Herring @ 2019-09-24 21:46 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Lorenzo Pieralisi; +Cc: linux-arm-kernel
In-Reply-To: <20190924214630.12817-1-robh@kernel.org>
Since commit a574795bc383 ("PCI: generic,versatile: Remove unused
pci_sys_data structures") the build dependency on ARM is gone, so let's
enable COMPILE_TEST for versatile.
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/pci/controller/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index fe9f9f13ce11..14836229357e 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -135,7 +135,7 @@ config PCI_V3_SEMI
config PCI_VERSATILE
bool "ARM Versatile PB PCI controller"
- depends on ARCH_VERSATILE
+ depends on ARCH_VERSATILE || COMPILE_TEST
config PCIE_IPROC
tristate
--
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 02/11] PCI: altera: Use pci_parse_request_of_pci_ranges()
From: Rob Herring @ 2019-09-24 21:46 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Lorenzo Pieralisi
Cc: Ley Foon Tan, rfi, linux-arm-kernel
In-Reply-To: <20190924214630.12817-1-robh@kernel.org>
Convert altera host bridge to use the common
pci_parse_request_of_pci_ranges().
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: rfi@lists.rocketboards.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/pci/controller/pcie-altera.c | 38 ++--------------------------
1 file changed, 2 insertions(+), 36 deletions(-)
diff --git a/drivers/pci/controller/pcie-altera.c b/drivers/pci/controller/pcie-altera.c
index d2497ca43828..2ed00babff5a 100644
--- a/drivers/pci/controller/pcie-altera.c
+++ b/drivers/pci/controller/pcie-altera.c
@@ -670,39 +670,6 @@ static void altera_pcie_isr(struct irq_desc *desc)
chained_irq_exit(chip, desc);
}
-static int altera_pcie_parse_request_of_pci_ranges(struct altera_pcie *pcie)
-{
- int err, res_valid = 0;
- struct device *dev = &pcie->pdev->dev;
- struct resource_entry *win;
-
- err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
- &pcie->resources, NULL);
- if (err)
- return err;
-
- err = devm_request_pci_bus_resources(dev, &pcie->resources);
- if (err)
- goto out_release_res;
-
- resource_list_for_each_entry(win, &pcie->resources) {
- struct resource *res = win->res;
-
- if (resource_type(res) == IORESOURCE_MEM)
- res_valid |= !(res->flags & IORESOURCE_PREFETCH);
- }
-
- if (res_valid)
- return 0;
-
- dev_err(dev, "non-prefetchable memory resource required\n");
- err = -EINVAL;
-
-out_release_res:
- pci_free_resource_list(&pcie->resources);
- return err;
-}
-
static int altera_pcie_init_irq_domain(struct altera_pcie *pcie)
{
struct device *dev = &pcie->pdev->dev;
@@ -833,9 +800,8 @@ static int altera_pcie_probe(struct platform_device *pdev)
return ret;
}
- INIT_LIST_HEAD(&pcie->resources);
-
- ret = altera_pcie_parse_request_of_pci_ranges(pcie);
+ ret = pci_parse_request_of_pci_ranges(dev, &pcie->resources,
+ NULL);
if (ret) {
dev_err(dev, "Failed add resources\n");
return ret;
--
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 01/11] PCI: aardvark: Use pci_parse_request_of_pci_ranges()
From: Rob Herring @ 2019-09-24 21:46 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Lorenzo Pieralisi
Cc: Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20190924214630.12817-1-robh@kernel.org>
Convert aardvark to use the common pci_parse_request_of_pci_ranges().
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/pci/controller/pci-aardvark.c | 58 ++-------------------------
1 file changed, 4 insertions(+), 54 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index fc0fe4d4de49..ff3af3d34028 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -910,63 +910,11 @@ static irqreturn_t advk_pcie_irq_handler(int irq, void *arg)
return IRQ_HANDLED;
}
-static int advk_pcie_parse_request_of_pci_ranges(struct advk_pcie *pcie)
-{
- int err, res_valid = 0;
- struct device *dev = &pcie->pdev->dev;
- struct resource_entry *win, *tmp;
- resource_size_t iobase;
-
- INIT_LIST_HEAD(&pcie->resources);
-
- err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
- &pcie->resources, &iobase);
- if (err)
- return err;
-
- err = devm_request_pci_bus_resources(dev, &pcie->resources);
- if (err)
- goto out_release_res;
-
- resource_list_for_each_entry_safe(win, tmp, &pcie->resources) {
- struct resource *res = win->res;
-
- switch (resource_type(res)) {
- case IORESOURCE_IO:
- err = devm_pci_remap_iospace(dev, res, iobase);
- if (err) {
- dev_warn(dev, "error %d: failed to map resource %pR\n",
- err, res);
- resource_list_destroy_entry(win);
- }
- break;
- case IORESOURCE_MEM:
- res_valid |= !(res->flags & IORESOURCE_PREFETCH);
- break;
- case IORESOURCE_BUS:
- pcie->root_bus_nr = res->start;
- break;
- }
- }
-
- if (!res_valid) {
- dev_err(dev, "non-prefetchable memory resource required\n");
- err = -EINVAL;
- goto out_release_res;
- }
-
- return 0;
-
-out_release_res:
- pci_free_resource_list(&pcie->resources);
- return err;
-}
-
static int advk_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct advk_pcie *pcie;
- struct resource *res;
+ struct resource *res, *bus;
struct pci_host_bridge *bridge;
int ret, irq;
@@ -991,11 +939,13 @@ static int advk_pcie_probe(struct platform_device *pdev)
return ret;
}
- ret = advk_pcie_parse_request_of_pci_ranges(pcie);
+ ret = pci_parse_request_of_pci_ranges(dev, &pcie->resources,
+ &bus);
if (ret) {
dev_err(dev, "Failed to parse resources\n");
return ret;
}
+ pcie->root_bus_nr = bus->start;
advk_pcie_setup_hw(pcie);
--
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 00/11] PCI dma-ranges parsing consolidation
From: Rob Herring @ 2019-09-24 21:46 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Lorenzo Pieralisi
Cc: Heiko Stuebner, Karthikeyan Mitran, Shawn Lin, Thomas Petazzoni,
Toan Le, Will Deacon, Ryder Lee, Michal Simek, linux-rockchip,
bcm-kernel-feedback-list, Linus Walleij, Ray Jui, Hou Zhiqiang,
Simon Horman, linux-mediatek, Matthias Brugger, linux-arm-kernel,
Scott Branden, Gustavo Pimentel, rfi, linux-renesas-soc,
Tom Joseph, Jingoo Han, Ley Foon Tan
This series moves the DT 'dma-ranges' parsing into common helpers
utilizing a resource list. In the process of doing this, I noticed
several cases where pci_parse_request_of_pci_ranges() could be used so
I converted those drivers first. The last 5 patches make the actual
change to use the common 'dma_ranges' resource list. There's no
(intended) functional change in this series though I'm also working on
a separate series to improve the handling of 'dma-ranges' and dma
masks.
pci-rcar-gen2 is the only remaining driver doing its own dma-ranges
handling as it is still using the old ARM PCI functions. Looks like it
is the last one (in drivers/pci/).
Compile tested only.
Rob
Rob Herring (11):
PCI: aardvark: Use pci_parse_request_of_pci_ranges()
PCI: altera: Use pci_parse_request_of_pci_ranges()
PCI: mediatek: Use pci_parse_request_of_pci_ranges()
PCI: versatile: Enable COMPILE_TEST
PCI: versatile: Use pci_parse_request_of_pci_ranges()
PCI: of: Add inbound resource parsing to helpers
PCI: ftpci100: Use inbound resources for setup
PCI: v3-semi: Use inbound resources for setup
PCI: xgene: Use inbound resources for setup
PCI: iproc: Use inbound resources for setup
PCI: rcar: Use inbound resources for setup
drivers/pci/controller/Kconfig | 2 +-
.../pci/controller/dwc/pcie-designware-host.c | 3 +-
drivers/pci/controller/pci-aardvark.c | 58 ++---------------
drivers/pci/controller/pci-ftpci100.c | 29 ++++-----
drivers/pci/controller/pci-host-common.c | 2 +-
drivers/pci/controller/pci-v3-semi.c | 40 +++++-------
drivers/pci/controller/pci-versatile.c | 62 ++++--------------
drivers/pci/controller/pci-xgene.c | 33 ++++------
drivers/pci/controller/pcie-altera.c | 38 +----------
drivers/pci/controller/pcie-cadence-host.c | 2 +-
drivers/pci/controller/pcie-iproc-platform.c | 1 +
drivers/pci/controller/pcie-iproc.c | 63 +++----------------
drivers/pci/controller/pcie-mediatek.c | 47 +++++---------
drivers/pci/controller/pcie-mobiveil.c | 4 +-
drivers/pci/controller/pcie-rcar.c | 48 ++++++--------
drivers/pci/controller/pcie-rockchip-host.c | 3 +-
drivers/pci/controller/pcie-xilinx-nwl.c | 2 +-
drivers/pci/controller/pcie-xilinx.c | 2 +-
drivers/pci/of.c | 44 ++++++++++++-
drivers/pci/pci.h | 8 ++-
include/linux/pci.h | 2 +
21 files changed, 162 insertions(+), 331 deletions(-)
--
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
* Re: [PATCH] mfd: mt6360: add pmic mt6360 driver
From: Lee Jones @ 2019-09-24 20:38 UTC (permalink / raw)
To: Gene Chen
Cc: gene_chen, linux-kernel, linux-mediatek, matthias.bgg, Wilma.Wu,
linux-arm-kernel, shufan_lee
In-Reply-To: <CAE+NS342Kn6OEz4D9Y0yfXStnW6KQ6N2yuQtgN2q2bXafofShg@mail.gmail.com>
On Tue, 24 Sep 2019, Gene Chen wrote:
> 2019-09-19 15:18 GMT+08:00, Lee Jones <lee.jones@linaro.org>:
> > On Thu, 19 Sep 2019, Gene Chen wrote:
> >
> >> Lee Jones <lee.jones@linaro.org> 於 2019年9月18日 週三 下午6:51寫道：
> >> >
> >> > On Wed, 18 Sep 2019, Gene Chen wrote:
> >> >
> >> > > From: Gene Chen <gene_chen@richtek.com>
> >> > >
> >> > > Add mfd driver for mt6360 pmic chip include
> >> > > Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck
> >> > >
> >> > > Signed-off-by: Gene Chen <gene_chen@richtek.com
> >> > > ---
> >> >
> >> > This looks different from the one you sent before, but I don't see a
> >> > version bump or any changelog in this space. Please re-submit with
> >> > the differences noted.
> >> >
> >>
> >> the change is
> >> 1. add missing include file
> >> 2. modify commit message
> >>
> >> this patch is regarded as version 1
> >
> > It's different to the first one you sent to the list, so it needs a
> > version bump and a change log. There also appears to still be issues
> > with it, if the auto-builders are to be believed.
> >
> > Do ensure you thoroughly test your patches before sending upstream.
> >
> > Please fix the issues and resubmit your v3 with a nice changelog.
> >
>
> thank you for suggestion
> may i ask how to disable kbuild test reboot for s390/x86_64/ia64?
> we want support only cross compiler = aarch64-linux-gnu-
> and we have test build pass with our patch
You can't and we wouldn't want to.
If this driver should only be built/tested for AArch64, you need to
ensure the Kconfig represents that.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: prsriva @ 2019-09-24 20:27 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: mark.rutland, jean-philippe, arnd, yamada.masahiro, sboyd,
catalin.marinas, kexec, linux-kernel, zohar, takahiro.akashi,
kristina.martsenko, duwe, linux-arm-kernel, james.morse,
linux-integrity, tglx, allison
In-Reply-To: <87zhiz1x9l.fsf@morokweng.localdomain>
On 9/19/19 8:07 PM, Thiago Jung Bauermann wrote:
>
> Hello Prakhar,
>
> Prakhar Srivastava <prsriva@linux.microsoft.com> writes:
>
>> During kexec_file_load, carrying forward the ima measurement log allows
>> a verifying party to get the entire runtime event log since the last
>> full reboot since that is when PCRs were last reset.
<snip>
> In the previous patch, you took the powerpc file and made a few
> modifications to fit your needs. This file is now somewhat different
> than the powerpc version, but I don't understand to what purpose. It's
> not different in any significant way.
>
> Based on review comments from your previous patch, I was expecting to
> see code from the powerpc file moved to an arch-independent part of the
> the kernel and possibly adapted so that both arm64 and powerpc could use
> it. Can you explain why you chose this approach instead? What is the
> advantage of having superficially different but basically equivalent
> code in the two architectures?
>
> Actually, there's one change that is significant: instead of a single
> linux,ima-kexec-buffer property holding the start address and size of
> the buffer, ARM64 is now using two properties (linux,ima-kexec-buffer
> and linux,ima-kexec-buffer-end) for the start and end addresses. In my
> opinion, unless there's a good reason for it Linux should be consistent
> accross architectures when possible.
>
> --
> Thiago Jung Bauermann
> IBM Linux Technology Center
I looked at the of_ drivers are it became apparent that the driver calls
were already available for consumption. Adding ima specific code will be
same as adding wrapper code for any other property. Which is true for
all properties, effectively setting the property name and pass through
for other parameters.
I still like to move both implementations to a arch independent code
path, i could not convince my self that of_*ima is probably the place,
but if that's the best place?, then i will go ahead and make that change
as well.
Regarding using two properties, it just seemed more consistent how the
properties(start-end) are being used in the kexec, and hides the inner
details for the cell structures, thats all.
Its just the placement of the wrapper functions, but once thats done
both archs will call the same.
Thanks,
Prakhar Srivastava
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: Thiago Jung Bauermann @ 2019-09-24 20:25 UTC (permalink / raw)
To: prsriva
Cc: mark.rutland, jean-philippe, arnd, yamada.masahiro, sboyd,
catalin.marinas, kexec, linux-kernel, zohar, takahiro.akashi,
kristina.martsenko, duwe, linux-arm-kernel, james.morse,
linux-integrity, tglx, allison
In-Reply-To: <02234482-b095-e064-f4d6-1c6255a4ff9f@linux.microsoft.com>
Hello,
prsriva <prsriva@linux.microsoft.com> writes:
> On 9/19/19 8:07 PM, Thiago Jung Bauermann wrote:
>> Hello Prakhar,
>>
>> Prakhar Srivastava <prsriva@linux.microsoft.com> writes:
>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 3adcec05b1f6..f39b12dbf9e8 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -976,6 +976,13 @@ config KEXEC_VERIFY_SIG
>>> verification for the corresponding kernel image type being
>>> loaded in order for this to work.
>>>
>>> +config HAVE_IMA_KEXEC
>>> + bool "Carry over IMA measurement log during kexec_file_load() syscall"
>>> + depends on KEXEC_FILE
>>> + help
>>> + Select this option to carry over IMA measurement log during
>>> + kexec_file_load.
>>> +
>>> config KEXEC_IMAGE_VERIFY_SIG
>>> bool "Enable Image signature verification support"
>>> default y
>> This is not right. As it stands, HAVE_IMA_KEXEC is essentially a synonym
>> for IMA_KEXEC.
>>
>> It's not meant to be user-visible in the config process. Instead, it's
>> meant to be selected by the arch Kconfig (probably by the ARM64 config
>> symbol) to signal to IMA's Kconfig that it can offer the IMA_KEXEC
>> option.
>>
>> I also mentioned in my previous review that config HAVE_IMA_KEXEC should
>> be defined in arch/Kconfig, not separately in both arch/arm64/Kconfig
>> and arch/powerpc/Kconfig.
>
> I see the entry exists in arch/Kconfig and is overwritten.
> I will remove entries both from powerpc and arm64.
>
> How do i cross-compile for powerpc?
There are some instructions here:
https://github.com/linuxppc/wiki/wiki/Building-powerpc-kernels
>>> diff --git a/arch/arm64/include/asm/ima.h b/arch/arm64/include/asm/ima.h
>>> new file mode 100644
>>> index 000000000000..e23cee84729f
>>> --- /dev/null
>>> +++ b/arch/arm64/include/asm/ima.h
>>> @@ -0,0 +1,29 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +#ifndef _ASM_ARM64_IMA_H
>>> +#define _ASM_ARM64_IMA_H
>>> +
>>> +struct kimage;
>>> +
>>> +int ima_get_kexec_buffer(void **addr, size_t *size);
>>> +int ima_free_kexec_buffer(void);
>>> +
>>> +#ifdef CONFIG_IMA
>>> +void remove_ima_buffer(void *fdt, int chosen_node);
>>> +#else
>>> +static inline void remove_ima_buffer(void *fdt, int chosen_node) {}
>>> +#endif
>> I mentioned in my previous review that remove_ima_buffer() should exist
>> even if CONFIG_IMA isn't set. Did you arrive at a different conclusion?
>
> I made the needed changed in makefile, missed removing the
>
> configs here. Thanks for pointing this out.
Thanks.
--
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
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] clk: at91: avoid sleeping early
From: Stephen Boyd @ 2019-09-24 20:20 UTC (permalink / raw)
To: Alexandre Belloni, u.kleine-koenig
Cc: Michael Turquette, linux-kernel, Claudiu Beznea, linux-clk,
linux-arm-kernel
In-Reply-To: <20190924122147.fojcu5u44letrele@pengutronix.de>
Quoting Uwe (2019-09-24 05:21:47)
> On Fri, Sep 20, 2019 at 05:39:06PM +0200, Alexandre Belloni wrote:
> > Note that this was already discussed a while ago and Arnd said this approach was
> > reasonable:
> > https://lore.kernel.org/lkml/6120818.MyeJZ74hYa@wuerfel/
> >
> > drivers/clk/at91/clk-main.c | 5 ++++-
> > drivers/clk/at91/sckc.c | 20 ++++++++++++++++----
> > 2 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
> > index f607ee702c83..ccd48e7a3d74 100644
> > --- a/drivers/clk/at91/clk-main.c
> > +++ b/drivers/clk/at91/clk-main.c
> > @@ -293,7 +293,10 @@ static int clk_main_probe_frequency(struct regmap *regmap)
> > regmap_read(regmap, AT91_CKGR_MCFR, &mcfr);
> > if (mcfr & AT91_PMC_MAINRDY)
> > return 0;
> > - usleep_range(MAINF_LOOP_MIN_WAIT, MAINF_LOOP_MAX_WAIT);
> > + if (system_state < SYSTEM_RUNNING)
> > + udelay(MAINF_LOOP_MIN_WAIT);
> > + else
> > + usleep_range(MAINF_LOOP_MIN_WAIT, MAINF_LOOP_MAX_WAIT);
>
> Given that this construct is introduced several times, I wonder if we
> want something like:
>
> static inline void early_usleep_range(unsigned long min, unsigned long max)
> {
> if (system_state < SYSTEM_RUNNING)
> udelay(min);
> else
> usleep_range(min, max);
> }
>
Maybe, but I think the intent is to not encourage this behavior? So
providing a wrapper will make it "easy" and then we'll have to tell
users to stop calling it. Another idea would be to make usleep_range()
"do the right thing" and call udelay if the system isn't running. And
another idea from tlgx[1] is to pull the delay logic into another clk op
that we can call to see when the enable or prepare is done. That may be
possible by introducing another clk_ops callback that when present
indicates we should sleep or delay for so much time while waiting for
the prepare or enable to complete.
[1] https://lkml.kernel.org/r/alpine.DEB.2.11.1606061448010.28031@nanos
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [arm:cex7 14/35] drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:362:15: error: variable 'mobiveil_msi_domain_info' has initializer but incomplete type
From: kbuild test robot @ 2019-09-24 19:58 UTC (permalink / raw)
To: Hou Zhiqiang
Cc: Minghuan Lian, Russell King, Subrahmanya Lingappa, kbuild-all,
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 18863 bytes --]
Hi Hou,
First bad commit (maybe != root cause):
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git cex7
head: 655ee1d87ab6a145c9fc22abc989936e47eebde6
commit: 2729e9ee9e99b04171a1cddddcd3027dd350dbde [14/35] PCI: mobiveil: Refactor Mobiveil PCIe Host Bridge IP driver
config: s390-allmodconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2729e9ee9e99b04171a1cddddcd3027dd350dbde
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=s390
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:362:15: error: variable 'mobiveil_msi_domain_info' has initializer but incomplete type
static struct msi_domain_info mobiveil_msi_domain_info = {
^~~~~~~~~~~~~~~
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:363:3: error: 'struct msi_domain_info' has no member named 'flags'
.flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
^~~~~
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:363:12: error: 'MSI_FLAG_USE_DEF_DOM_OPS' undeclared here (not in a function); did you mean 'SIMPLE_DEV_PM_OPS'?
.flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
^~~~~~~~~~~~~~~~~~~~~~~~
SIMPLE_DEV_PM_OPS
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:363:39: error: 'MSI_FLAG_USE_DEF_CHIP_OPS' undeclared here (not in a function); did you mean 'MSI_FLAG_USE_DEF_DOM_OPS'?
.flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
^~~~~~~~~~~~~~~~~~~~~~~~~
MSI_FLAG_USE_DEF_DOM_OPS
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:364:6: error: 'MSI_FLAG_PCI_MSIX' undeclared here (not in a function); did you mean 'CONFIG_PCI_MSI'?
MSI_FLAG_PCI_MSIX),
^~~~~~~~~~~~~~~~~
CONFIG_PCI_MSI
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:363:11: warning: excess elements in struct initializer
.flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
^
drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:363:11: note: (near initialization for 'mobiveil_msi_domain_info')
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:365:3: error: 'struct msi_domain_info' has no member named 'chip'
.chip = &mobiveil_msi_irq_chip,
^~~~
drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:365:10: warning: excess elements in struct initializer
.chip = &mobiveil_msi_irq_chip,
^
drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:365:10: note: (near initialization for 'mobiveil_msi_domain_info')
drivers/pci/controller/mobiveil/pcie-mobiveil-host.c: In function 'mobiveil_allocate_msi_domains':
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:456:20: error: implicit declaration of function 'pci_msi_create_irq_domain'; did you mean 'pci_msi_get_device_domain'? [-Werror=implicit-function-declaration]
msi->msi_domain = pci_msi_create_irq_domain(fwnode,
^~~~~~~~~~~~~~~~~~~~~~~~~
pci_msi_get_device_domain
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:456:18: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
msi->msi_domain = pci_msi_create_irq_domain(fwnode,
^
drivers/pci/controller/mobiveil/pcie-mobiveil-host.c: At top level:
>> drivers/pci/controller/mobiveil/pcie-mobiveil-host.c:362:31: error: storage size of 'mobiveil_msi_domain_info' isn't known
static struct msi_domain_info mobiveil_msi_domain_info = {
^~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/mobiveil_msi_domain_info +362 drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 361
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 @362 static struct msi_domain_info mobiveil_msi_domain_info = {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 @363 .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
a131fb6364c1be drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 @364 MSI_FLAG_PCI_MSIX),
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 @365 .chip = &mobiveil_msi_irq_chip,
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 366 };
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 367
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 368 static void mobiveil_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 369 {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 370 struct mobiveil_pcie *pcie = irq_data_get_irq_chip_data(data);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 371 phys_addr_t addr = pcie->pcie_reg_base + (data->hwirq * sizeof(int));
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 372
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 373 msg->address_lo = lower_32_bits(addr);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 374 msg->address_hi = upper_32_bits(addr);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 375 msg->data = data->hwirq;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 376
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 377 dev_dbg(&pcie->pdev->dev, "msi#%d address_hi %#x address_lo %#x\n",
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 378 (int)data->hwirq, msg->address_hi, msg->address_lo);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 379 }
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 380
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 381 static int mobiveil_msi_set_affinity(struct irq_data *irq_data,
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 382 const struct cpumask *mask, bool force)
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 383 {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 384 return -EINVAL;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 385 }
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 386
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 387 static struct irq_chip mobiveil_msi_bottom_irq_chip = {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 388 .name = "Mobiveil MSI",
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 389 .irq_compose_msi_msg = mobiveil_compose_msi_msg,
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 390 .irq_set_affinity = mobiveil_msi_set_affinity,
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 391 };
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 392
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 393 static int mobiveil_irq_msi_domain_alloc(struct irq_domain *domain,
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 394 unsigned int virq,
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 395 unsigned int nr_irqs, void *args)
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 396 {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 397 struct mobiveil_pcie *pcie = domain->host_data;
2729e9ee9e99b0 drivers/pci/controller/mobiveil/pcie-mobiveil-host.c Hou Zhiqiang 2019-08-13 398 struct mobiveil_msi *msi = &pcie->rp.msi;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 399 unsigned long bit;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 400
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 401 WARN_ON(nr_irqs != 1);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 402 mutex_lock(&msi->lock);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 403
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 404 bit = find_first_zero_bit(msi->msi_irq_in_use, msi->num_of_vectors);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 405 if (bit >= msi->num_of_vectors) {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 406 mutex_unlock(&msi->lock);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 407 return -ENOSPC;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 408 }
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 409
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 410 set_bit(bit, msi->msi_irq_in_use);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 411
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 412 mutex_unlock(&msi->lock);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 413
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 414 irq_domain_set_info(domain, virq, bit, &mobiveil_msi_bottom_irq_chip,
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 415 domain->host_data, handle_level_irq, NULL, NULL);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 416 return 0;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 417 }
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 418
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 419 static void mobiveil_irq_msi_domain_free(struct irq_domain *domain,
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 420 unsigned int virq,
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 421 unsigned int nr_irqs)
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 422 {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 423 struct irq_data *d = irq_domain_get_irq_data(domain, virq);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 424 struct mobiveil_pcie *pcie = irq_data_get_irq_chip_data(d);
2729e9ee9e99b0 drivers/pci/controller/mobiveil/pcie-mobiveil-host.c Hou Zhiqiang 2019-08-13 425 struct mobiveil_msi *msi = &pcie->rp.msi;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 426
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 427 mutex_lock(&msi->lock);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 428
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 429 if (!test_bit(d->hwirq, msi->msi_irq_in_use))
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 430 dev_err(&pcie->pdev->dev, "trying to free unused MSI#%lu\n",
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 431 d->hwirq);
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 432 else
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 433 __clear_bit(d->hwirq, msi->msi_irq_in_use);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 434
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 435 mutex_unlock(&msi->lock);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 436 }
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 437 static const struct irq_domain_ops msi_domain_ops = {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 438 .alloc = mobiveil_irq_msi_domain_alloc,
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 439 .free = mobiveil_irq_msi_domain_free,
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 440 };
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 441
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 442 static int mobiveil_allocate_msi_domains(struct mobiveil_pcie *pcie)
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 443 {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 444 struct device *dev = &pcie->pdev->dev;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 445 struct fwnode_handle *fwnode = of_node_to_fwnode(dev->of_node);
2729e9ee9e99b0 drivers/pci/controller/mobiveil/pcie-mobiveil-host.c Hou Zhiqiang 2019-08-13 446 struct mobiveil_msi *msi = &pcie->rp.msi;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 447
2729e9ee9e99b0 drivers/pci/controller/mobiveil/pcie-mobiveil-host.c Hou Zhiqiang 2019-08-13 448 mutex_init(&msi->lock);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 449 msi->dev_domain = irq_domain_add_linear(NULL, msi->num_of_vectors,
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 450 &msi_domain_ops, pcie);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 451 if (!msi->dev_domain) {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 452 dev_err(dev, "failed to create IRQ domain\n");
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 453 return -ENOMEM;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 454 }
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 455
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 @456 msi->msi_domain = pci_msi_create_irq_domain(fwnode,
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 457 &mobiveil_msi_domain_info,
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 458 msi->dev_domain);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 459 if (!msi->msi_domain) {
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 460 dev_err(dev, "failed to create MSI domain\n");
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 461 irq_domain_remove(msi->dev_domain);
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 462 return -ENOMEM;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 463 }
e369faf6255df5 drivers/pci/controller/pcie-mobiveil.c Hou Zhiqiang 2019-07-05 464
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 465 return 0;
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 466 }
1e913e58335fbc drivers/pci/host/pcie-mobiveil.c Subrahmanya Lingappa 2018-05-30 467
:::::: The code at line 362 was first introduced by commit
:::::: 1e913e58335fbc7a8da9662746dd54d6091488b8 PCI: mobiveil: Add MSI support
:::::: TO: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
:::::: CC: Bjorn Helgaas <bhelgaas@google.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 55857 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: prsriva @ 2019-09-24 19:54 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: mark.rutland, jean-philippe, arnd, yamada.masahiro, sboyd,
catalin.marinas, kexec, linux-kernel, zohar, takahiro.akashi,
kristina.martsenko, duwe, linux-arm-kernel, james.morse,
linux-integrity, tglx, allison
In-Reply-To: <87zhiz1x9l.fsf@morokweng.localdomain>
On 9/19/19 8:07 PM, Thiago Jung Bauermann wrote:
> Hello Prakhar,
>
> Prakhar Srivastava <prsriva@linux.microsoft.com> writes:
>
>> During kexec_file_load, carrying forward the ima measurement log allows
>> a verifying party to get the entire runtime event log since the last
>> full reboot since that is when PCRs were last reset.
>>
>> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
>> ---
>> arch/arm64/Kconfig | 7 +
>> arch/arm64/include/asm/ima.h | 29 ++++
>> arch/arm64/include/asm/kexec.h | 5 +
>> arch/arm64/kernel/Makefile | 3 +-
>> arch/arm64/kernel/ima_kexec.c | 213 +++++++++++++++++++++++++
>> arch/arm64/kernel/machine_kexec_file.c | 6 +
>> 6 files changed, 262 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm64/include/asm/ima.h
>> create mode 100644 arch/arm64/kernel/ima_kexec.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 3adcec05b1f6..f39b12dbf9e8 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -976,6 +976,13 @@ config KEXEC_VERIFY_SIG
>> verification for the corresponding kernel image type being
>> loaded in order for this to work.
>>
>> +config HAVE_IMA_KEXEC
>> + bool "Carry over IMA measurement log during kexec_file_load() syscall"
>> + depends on KEXEC_FILE
>> + help
>> + Select this option to carry over IMA measurement log during
>> + kexec_file_load.
>> +
>> config KEXEC_IMAGE_VERIFY_SIG
>> bool "Enable Image signature verification support"
>> default y
> This is not right. As it stands, HAVE_IMA_KEXEC is essentially a synonym
> for IMA_KEXEC.
>
> It's not meant to be user-visible in the config process. Instead, it's
> meant to be selected by the arch Kconfig (probably by the ARM64 config
> symbol) to signal to IMA's Kconfig that it can offer the IMA_KEXEC
> option.
>
> I also mentioned in my previous review that config HAVE_IMA_KEXEC should
> be defined in arch/Kconfig, not separately in both arch/arm64/Kconfig
> and arch/powerpc/Kconfig.
I see the entry exists in arch/Kconfig and is overwritten.
I will remove entries both from powerpc and arm64.
How do i cross-compile for powerpc?
>
>> diff --git a/arch/arm64/include/asm/ima.h b/arch/arm64/include/asm/ima.h
>> new file mode 100644
>> index 000000000000..e23cee84729f
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/ima.h
>> @@ -0,0 +1,29 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _ASM_ARM64_IMA_H
>> +#define _ASM_ARM64_IMA_H
>> +
>> +struct kimage;
>> +
>> +int ima_get_kexec_buffer(void **addr, size_t *size);
>> +int ima_free_kexec_buffer(void);
>> +
>> +#ifdef CONFIG_IMA
>> +void remove_ima_buffer(void *fdt, int chosen_node);
>> +#else
>> +static inline void remove_ima_buffer(void *fdt, int chosen_node) {}
>> +#endif
> I mentioned in my previous review that remove_ima_buffer() should exist
> even if CONFIG_IMA isn't set. Did you arrive at a different conclusion?
I made the needed changed in makefile, missed removing the
configs here. Thanks for pointing this out.
>> +
>> +#ifdef CONFIG_IMA_KEXEC
>> +int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
>> + size_t size);
>> +
>> +int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node);
>> +#else
>> +static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
>> + int chosen_node)
>> +{
>> + remove_ima_buffer(fdt, chosen_node);
>> + return 0;
>> +}
>> +#endif /* CONFIG_IMA_KEXEC */
>> +#endif /* _ASM_ARM64_IMA_H */
>> diff --git a/arch/arm64/kernel/ima_kexec.c b/arch/arm64/kernel/ima_kexec.c
>> new file mode 100644
>> index 000000000000..b14326d541f3
>> --- /dev/null
>> +++ b/arch/arm64/kernel/ima_kexec.c
> In the previous patch, you took the powerpc file and made a few
> modifications to fit your needs. This file is now somewhat different
> than the powerpc version, but I don't understand to what purpose. It's
> not different in any significant way.
>
> Based on review comments from your previous patch, I was expecting to
> see code from the powerpc file moved to an arch-independent part of the
> the kernel and possibly adapted so that both arm64 and powerpc could use
> it. Can you explain why you chose this approach instead? What is the
> advantage of having superficially different but basically equivalent
> code in the two architectures?
>
> Actually, there's one change that is significant: instead of a single
> linux,ima-kexec-buffer property holding the start address and size of
> the buffer, ARM64 is now using two properties (linux,ima-kexec-buffer
> and linux,ima-kexec-buffer-end) for the start and end addresses. In my
> opinion, unless there's a good reason for it Linux should be consistent
> accross architectures when possible.
>
> --
> Thiago Jung Bauermann
> IBM Linux Technology Center
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Re: [PATCH 0/9] added helper macros to remove duplicate code from probe functions of the platform drivers
From: Vinod Koul @ 2019-09-24 19:27 UTC (permalink / raw)
To: Satendra Singh Thakur
Cc: lars, maxime.ripard, sean.wang, linux-kernel, afaerber, dmaengine,
wens, agross, linux-mediatek, satendrasingh.thakur,
manivannan.sadhasivam, matthias.bgg, dan.j.williams, shawnguo,
jun.nie, linux-arm-kernel
In-Reply-To: <2356e29bca5bdfa901534bb32a2782185eb0415f.1568909689.git.sst2005@gmail.com>
On 21-09-19, 20:27, Satendra Singh Thakur wrote:
> On Wed, Sep 18, 2019 at 3:57 PM, Vinod Koul wrote:
> > On 15-09-19, 12:30, Satendra Singh Thakur wrote:
> > > 1. For most of the platform drivers's probe include following steps
> > >
> > > -memory allocation for driver's private structure
> > > -getting io resources
> > > -io remapping resources
> > > -getting irq number
> > > -registering irq
> > > -setting driver's private data
> > > -getting clock
> > > -preparing and enabling clock
> >
> > And we have perfect set of APIs for these tasks!
> Hi Vinod,
> Thanks for the comments.
> You are right, we already have set of APIs for these tasks.
> The proposed macros combine the very same APIs to remove
> duplicate/redundant code.
> A new driver author can use these macros to easily write probe
Nope they can write each APIs, know the exact flow and do it!
> function without having to worry about signatures of internal APIs.
> In the past, people have combined some of them e.g.
> a) clk_prepare_enable combines clk_prepare and clk_enable
As it is clock, it is called in sequence, whereas different drivers may
have different sequencing.
Btw I am not for adding maanged irq functions, they are really not the
correct way to manage!
> b) devm_platform_ioremap_resource combines
> platform_get_resource (for type IORESOURCE_MEM)
> and devm_ioremap_resource
> c) module_platform_driver macro encompasses module_init/exit
> and driver_register/unregister functions.
All examples you are quoting do a set of functions (clk, resources etc
and not do N things!
> The basic idea is to simplyfy coding.
> > > 2. We have defined a set of macros to combine some or all of
> > > the above mentioned steps. This will remove redundant/duplicate
> > > code in drivers' probe functions of platform drivers.
> >
> > Why, how does it help and you do realize it also introduces bugs
> This will make probe function shorter by removing repeated code.
> This will also reduce bugs caused due to improper handling
> of failure cases because of these reasons:
> a) If the developer calls each API individualy one might miss
> proper handling of the failure for some API; Whereas the macro
> properly handles failure of each API.
> b) Macros are devres compatible which leaves less room for
> memory leaks.
No we review the code and if we miss we fix later!
> Yes, the macros which enable clock and request irqs
> might cause bugs if they are not used carefully.
> For instance, enabling the clock or requesting the irq
> earlier than actually required. So, the macros with _clk
> and _irq, _all suffix should be used carefully.
Precisely!
> Please let me know if I miss any specific type of bug
> here.
> >
> > > devm_platform_probe_helper(pdev, priv, clk_name);
> > > devm_platform_probe_helper_clk(pdev, priv, clk_name);
> > > devm_platform_probe_helper_irq(pdev, priv, clk_name,
> > > irq_hndlr, irq_flags, irq_name, irq_devid);
> > > devm_platform_probe_helper_all(pdev, priv, clk_name,
> > > irq_hndlr, irq_flags, irq_name, irq_devid);
> > > devm_platform_probe_helper_all_data(pdev, priv, clk_name,
> > > irq_hndlr, irq_flags, irq_name, irq_devid);
> > >
> > > 3. Code is made devres compatible (wherever required)
> > > The functions: clk_get, request_irq, kzalloc, platform_get_resource
> > > are replaced with their devm_* counterparts.
> >
> > We already have devres APIs for people to use!
> Yes, we have devres APIs and many drivers do use them.
> But still there are many which don't use them.
> The proposed macros provides just another way to use devres APIs.
> > >
> > > 4. Few bugs are also fixed.
> >
> > Which ones..?
> The bug is that the failure of request_irq
> is not handled properly in mtk-hsdma.c. This is fixed in patch [5/9].
> https://lkml.org/lkml/2019/9/15/35
Please send the fix individually and I would be glad to review.
--
~Vinod
_______________________________________________
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 v8 5/6] PM / devfreq: Add PM QoS support
From: Leonard Crestez @ 2019-09-24 19:22 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, dl-linux-imx,
Krzysztof Kozlowski, Lukasz Luba, Chanwoo Choi, Kyungmin Park,
MyungJoo Ham, Alexandre Bailon, Georgi Djakov,
linux-arm-kernel@lists.infradead.org, Jacky Bai
In-Reply-To: <20190924191124.GJ133864@google.com>
On 24.09.2019 22:11, Matthias Kaehlcke wrote:
> On Tue, Sep 24, 2019 at 01:11:29PM +0300, Leonard Crestez wrote:
>> Register notifiers with the PM QoS framework in order to respond to
>> requests for DEV_PM_QOS_MIN_FREQUENCY and DEV_PM_QOS_MAX_FREQUENCY.
>>
>> No notifiers are added by this patch but PM QoS constraints can be
>> imposed externally (for example from other devices).
>>
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
>> ---
>> drivers/devfreq/devfreq.c | 75 +++++++++++++++++++++++++++++++++++++++
>> include/linux/devfreq.h | 5 +++
>> 2 files changed, 80 insertions(+)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index eee403e70c84..784f3e40536a 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -22,15 +22,18 @@
>> #include <linux/platform_device.h>
>> #include <linux/list.h>
>> #include <linux/printk.h>
>> #include <linux/hrtimer.h>
>> #include <linux/of.h>
>> +#include <linux/pm_qos.h>
>> #include "governor.h"
>>
>> #define CREATE_TRACE_POINTS
>> #include <trace/events/devfreq.h>
>>
>> +#define HZ_PER_KHZ 1000
>> +
>> static struct class *devfreq_class;
>>
>> /*
>> * devfreq core provides delayed work based load monitoring helper
>> * functions. Governors can use these or can implement their own
>> @@ -109,10 +112,11 @@ static unsigned long find_available_max_freq(struct devfreq *devfreq)
>> static void get_freq_range(struct devfreq *devfreq,
>> unsigned long *min_freq,
>> unsigned long *max_freq)
>> {
>> unsigned long *freq_table = devfreq->profile->freq_table;
>> + unsigned long qos_min_freq, qos_max_freq;
>>
>> lockdep_assert_held(&devfreq->lock);
>>
>> /*
>> * Init min/max frequency from freq table.
>> @@ -125,10 +129,18 @@ static void get_freq_range(struct devfreq *devfreq,
>> } else {
>> *min_freq = freq_table[devfreq->profile->max_state - 1];
>> *max_freq = freq_table[0];
>> }
>>
>> + /* constraints from PM QoS */
>> + qos_min_freq = dev_pm_qos_read_value(devfreq->dev.parent,
>> + DEV_PM_QOS_MIN_FREQUENCY);
>> + qos_max_freq = dev_pm_qos_read_value(devfreq->dev.parent,
>> + DEV_PM_QOS_MIN_FREQUENCY); >
> This needs to be DEV_PM_QOS_MAX_FREQUENCY. I missed this in the earlier
> reviews, but stumbled across it when testing.
>
> !Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
I broke it in v8 while processing comments. Thanks for catching it.
--
Regards,
Leonard
_______________________________________________
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 v5 0/3] arm64: meson-g12b: Add support for the Ugoos AM6
From: Kevin Hilman @ 2019-09-24 19:18 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Oleg Ivanov, Christian Hewitt
In-Reply-To: <1569248036-6729-1-git-send-email-christianshewitt@gmail.com>
Christian Hewitt <christianshewitt@gmail.com> writes:
> This patchset adds support for the Ugoos AM6, an Android STB based on
> the Amlogic W400 reference design with the S922X chipset.
>
> v2: correction of minor nits
>
> v3: address regulator and GPIO corrections from Neil Armstrong (using
> schematic excerpts from Ugoos) and related v2 comments from Martin
> Blumenstingle. Add acks on patches 1/2 from Rob Herring.
>
> v4: address nits from Martin except for the vcc_3v3 node as it's not
> known how to handle the vcc_3v3 regulator managed by ATF firmware, so
> it remains untouched/undeclared like other g12a/g12b/sm1 boards.
>
> v5: corrected some tabs v spaces issues introduced in v4.
Queued for v5.5,
Thanks,
Kevin
_______________________________________________
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 v8 5/6] PM / devfreq: Add PM QoS support
From: Matthias Kaehlcke @ 2019-09-24 19:11 UTC (permalink / raw)
To: Leonard Crestez
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan, linux-pm,
Viresh Kumar, NXP Linux Team, Krzysztof Kozlowski, Lukasz Luba,
Chanwoo Choi, Kyungmin Park, MyungJoo Ham, Alexandre Bailon,
Georgi Djakov, linux-arm-kernel, Jacky Bai
In-Reply-To: <58fdd2c226a4e76a3d9427baab7dd5c23af842ab.1569319738.git.leonard.crestez@nxp.com>
On Tue, Sep 24, 2019 at 01:11:29PM +0300, Leonard Crestez wrote:
> Register notifiers with the PM QoS framework in order to respond to
> requests for DEV_PM_QOS_MIN_FREQUENCY and DEV_PM_QOS_MAX_FREQUENCY.
>
> No notifiers are added by this patch but PM QoS constraints can be
> imposed externally (for example from other devices).
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> drivers/devfreq/devfreq.c | 75 +++++++++++++++++++++++++++++++++++++++
> include/linux/devfreq.h | 5 +++
> 2 files changed, 80 insertions(+)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index eee403e70c84..784f3e40536a 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -22,15 +22,18 @@
> #include <linux/platform_device.h>
> #include <linux/list.h>
> #include <linux/printk.h>
> #include <linux/hrtimer.h>
> #include <linux/of.h>
> +#include <linux/pm_qos.h>
> #include "governor.h"
>
> #define CREATE_TRACE_POINTS
> #include <trace/events/devfreq.h>
>
> +#define HZ_PER_KHZ 1000
> +
> static struct class *devfreq_class;
>
> /*
> * devfreq core provides delayed work based load monitoring helper
> * functions. Governors can use these or can implement their own
> @@ -109,10 +112,11 @@ static unsigned long find_available_max_freq(struct devfreq *devfreq)
> static void get_freq_range(struct devfreq *devfreq,
> unsigned long *min_freq,
> unsigned long *max_freq)
> {
> unsigned long *freq_table = devfreq->profile->freq_table;
> + unsigned long qos_min_freq, qos_max_freq;
>
> lockdep_assert_held(&devfreq->lock);
>
> /*
> * Init min/max frequency from freq table.
> @@ -125,10 +129,18 @@ static void get_freq_range(struct devfreq *devfreq,
> } else {
> *min_freq = freq_table[devfreq->profile->max_state - 1];
> *max_freq = freq_table[0];
> }
>
> + /* constraints from PM QoS */
> + qos_min_freq = dev_pm_qos_read_value(devfreq->dev.parent,
> + DEV_PM_QOS_MIN_FREQUENCY);
> + qos_max_freq = dev_pm_qos_read_value(devfreq->dev.parent,
> + DEV_PM_QOS_MIN_FREQUENCY);
This needs to be DEV_PM_QOS_MAX_FREQUENCY. I missed this in the earlier
reviews, but stumbled across it when testing.
!Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
_______________________________________________
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] arm64: dts: meson: Add capacity-dmips-mhz attributes to G12B
From: Kevin Hilman @ 2019-09-24 19:10 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Frank Hartung, Christian Hewitt
In-Reply-To: <1568429380-3231-1-git-send-email-christianshewitt@gmail.com>
Christian Hewitt <christianshewitt@gmail.com> writes:
> From: Frank Hartung <supervisedthinking@gmail.com>
>
> From: Frank Hartung <supervisedthinking@gmail.com>
nit: duplicate From line. Removed when applying.
> Meson G12B SoCs (S922X and A311D) are a big-little design where not all CPUs
> are equal; the A53s cores are weaker than the A72s.
>
> Include capacity-dmips-mhz properties to tell the OS there is a difference
> in processing capacity. The dmips values are based on similar submissions for
> other A53/A72 SoCs: HiSilicon 3660 [1] and Rockchip RK3399 [2].
>
> This change is particularly beneficial for use-cases like retro gaming where
> emulators often run on a single core. The OS now chooses an A72 core instead
> of an A53 core.
>
> [1] https://lore.kernel.org/patchwork/patch/862742/
> [2] https://patchwork.kernel.org/patch/10836577/
>
> Signed-off-by: Frank Hartung <supervisedthinking@gmail.com>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Queued for v5.5,
Thanks!
Kevin
_______________________________________________
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 v4 0/4] arm64: Add basic support for Amlogic A1 SoC Family
From: Kevin Hilman @ 2019-09-24 19:07 UTC (permalink / raw)
To: Jianxin Pan, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1568276370-54181-1-git-send-email-jianxin.pan@amlogic.com>
Jianxin Pan <jianxin.pan@amlogic.com> writes:
> A1 is an application processor designed for smart audio and IoT applications,
> with Dual core ARM Cortex-A35 CPU. Unlike the previous GXL and G12 series,
> there is no Cortex-M3 AO CPU in it.
>
> This serial add basic support for the Amlogic A1 based Amlogic AD401 board:
> which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
> Timer, UART. It's capable of booting up into the serial console.
>
> The pclk for uart_AO_B need to be fixed once A1 clock driver is merged.
> In this version, it rely on bootloader to enable the pclk gate
Queued for v5.5,
Thanks for the new SoC support,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [v1, 1/1] gpio: dts: aspeed: Add SGPIO driver
From: Hongwei Zhang @ 2019-09-24 19:07 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, linux-gpio, Joel Stanley
Cc: Mark Rutland, devicetree, Arnd Bergmann, linux-aspeed,
Ard Biesheuvel, Masahiro Yamada, linux-kernel, Russell King,
Mike Rapoport, Bartosz Golaszewski, Rob Herring,
Benjamin Gaignard, Mauro Carvalho Chehab, Doug Anderson,
Andrew Morton, Hongwei Zhang, linux-arm-kernel
Add SGPIO driver support for Aspeed AST2500 SoC.
Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
---
arch/arm/Kconfig | 2 ++
arch/arm/boot/dts/aspeed-g5.dtsi | 16 +++++++++++++++-
drivers/gpio/Kconfig | 8 ++++++++
drivers/gpio/Makefile | 1 +
4 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2436021..c9f08ab 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1460,6 +1460,8 @@ config ARCH_NR_GPIO
default 416 if ARCH_SUNXI
default 392 if ARCH_U8500
default 352 if ARCH_VT8500
+ default 312 if MACH_ASPEED_G5
+ default 304 if MACH_ASPEED_G4
default 288 if ARCH_ROCKCHIP
default 264 if MACH_H4700
default 0
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 00f05bd..85da7ea 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -311,7 +311,7 @@
#gpio-cells = <2>;
gpio-controller;
compatible = "aspeed,ast2500-gpio";
- reg = <0x1e780000 0x1000>;
+ reg = <0x1e780000 0x200>;
interrupts = <20>;
gpio-ranges = <&pinctrl 0 0 232>;
clocks = <&syscon ASPEED_CLK_APB>;
@@ -319,6 +319,20 @@
#interrupt-cells = <2>;
};
+ sgpio: sgpio@1e780200 {
+ #gpio-cells = <2>;
+ compatible = "aspeed,ast2500-sgpio";
+ gpio-controller;
+ interrupts = <40>;
+ reg = <0x1e780200 0x0100>;
+ clocks = <&syscon ASPEED_CLK_APB>;
+ interrupt-controller;
+ ngpios = <8>;
+ bus-frequency = <12000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sgpm_default>;
+ };
+
rtc: rtc@1e781000 {
compatible = "aspeed,ast2500-rtc";
reg = <0x1e781000 0x18>;
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bb13c26..e94f903 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -120,6 +120,14 @@ config GPIO_ASPEED
help
Say Y here to support Aspeed AST2400 and AST2500 GPIO controllers.
+config SGPIO_ASPEED
+ bool "Aspeed SGPIO support"
+ depends on (ARCH_ASPEED || COMPILE_TEST) && OF_GPIO
+ select GPIO_GENERIC
+ select GPIOLIB_IRQCHIP
+ help
+ Say Y here to support Aspeed AST2500 SGPIO functionality.
+
config GPIO_ATH79
tristate "Atheros AR71XX/AR724X/AR913X GPIO support"
default y if ATH79
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a4e9117..bebbd82 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_GPIO_AMD_FCH) += gpio-amd-fch.o
obj-$(CONFIG_GPIO_AMDPT) += gpio-amdpt.o
obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
obj-$(CONFIG_GPIO_ASPEED) += gpio-aspeed.o
+obj-$(CONFIG_SGPIO_ASPEED) += sgpio-aspeed.o
obj-$(CONFIG_GPIO_ATH79) += gpio-ath79.o
obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BD70528) += gpio-bd70528.o
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [v1, 0/1] gpio: dts: aspeed: Add SGPIO driver
From: Hongwei Zhang @ 2019-09-24 19:02 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, linux-gpio, Joel Stanley
Cc: Mark Rutland, devicetree, Arnd Bergmann, linux-aspeed,
Ard Biesheuvel, Masahiro Yamada, linux-kernel, Russell King,
Mike Rapoport, Bartosz Golaszewski, Rob Herring,
Benjamin Gaignard, Mauro Carvalho Chehab, Doug Anderson,
Andrew Morton, Hongwei Zhang, linux-arm-kernel
In-Reply-To: <1569351740-6285-1-git-send-email-hongweiz@ami.com>
Add SGPIO driver support for Aspeed AST2500 SoC.
Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
---
arch/arm/Kconfig | 2 ++
arch/arm/boot/dts/aspeed-g5.dtsi | 16 +++++++++++++++-
drivers/gpio/Kconfig | 8 ++++++++
drivers/gpio/Makefile | 1 +
4 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2436021..c9f08ab 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1460,6 +1460,8 @@ config ARCH_NR_GPIO
default 416 if ARCH_SUNXI
default 392 if ARCH_U8500
default 352 if ARCH_VT8500
+ default 312 if MACH_ASPEED_G5
+ default 304 if MACH_ASPEED_G4
default 288 if ARCH_ROCKCHIP
default 264 if MACH_H4700
default 0
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 00f05bd..85da7ea 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -311,7 +311,7 @@
#gpio-cells = <2>;
gpio-controller;
compatible = "aspeed,ast2500-gpio";
- reg = <0x1e780000 0x1000>;
+ reg = <0x1e780000 0x200>;
interrupts = <20>;
gpio-ranges = <&pinctrl 0 0 232>;
clocks = <&syscon ASPEED_CLK_APB>;
@@ -319,6 +319,20 @@
#interrupt-cells = <2>;
};
+ sgpio: sgpio@1e780200 {
+ #gpio-cells = <2>;
+ compatible = "aspeed,ast2500-sgpio";
+ gpio-controller;
+ interrupts = <40>;
+ reg = <0x1e780200 0x0100>;
+ clocks = <&syscon ASPEED_CLK_APB>;
+ interrupt-controller;
+ ngpios = <8>;
+ bus-frequency = <12000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sgpm_default>;
+ };
+
rtc: rtc@1e781000 {
compatible = "aspeed,ast2500-rtc";
reg = <0x1e781000 0x18>;
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bb13c26..e94f903 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -120,6 +120,14 @@ config GPIO_ASPEED
help
Say Y here to support Aspeed AST2400 and AST2500 GPIO controllers.
+config SGPIO_ASPEED
+ bool "Aspeed SGPIO support"
+ depends on (ARCH_ASPEED || COMPILE_TEST) && OF_GPIO
+ select GPIO_GENERIC
+ select GPIOLIB_IRQCHIP
+ help
+ Say Y here to support Aspeed AST2500 SGPIO functionality.
+
config GPIO_ATH79
tristate "Atheros AR71XX/AR724X/AR913X GPIO support"
default y if ATH79
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a4e9117..bebbd82 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_GPIO_AMD_FCH) += gpio-amd-fch.o
obj-$(CONFIG_GPIO_AMDPT) += gpio-amdpt.o
obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
obj-$(CONFIG_GPIO_ASPEED) += gpio-aspeed.o
+obj-$(CONFIG_SGPIO_ASPEED) += sgpio-aspeed.o
obj-$(CONFIG_GPIO_ATH79) += gpio-ath79.o
obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BD70528) += gpio-bd70528.o
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [v1, 0/1] gpio: dts: aspeed: Add SGPIO driver
From: Hongwei Zhang @ 2019-09-24 19:02 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, linux-gpio, Joel Stanley
Cc: Mark Rutland, devicetree, Arnd Bergmann, linux-aspeed,
Ard Biesheuvel, Masahiro Yamada, linux-kernel, Russell King,
Mike Rapoport, Bartosz Golaszewski, Rob Herring,
Benjamin Gaignard, Mauro Carvalho Chehab, Doug Anderson,
Andrew Morton, Hongwei Zhang, linux-arm-kernel
Hello,
This short series introduce the Kconfig, Makefile, and dts for the
Aspeed AST2500 SGPIO controller. This is the last patch set.
Please review.
[v1]: Initial commit
The related SGPIO driver has been accepted and merged into v5.4:
_http://patchwork.ozlabs.org/patch/1150357/
The related SGPM pinmux dt-binding document, dts, and pinctrl driver
updates have been accepted and merged:
_http://patchwork.ozlabs.org/patch/1110210/
Thanks!
Hongwei Zhang (1):
gpio: dts: aspeed: Add SGPIO driver
arch/arm/Kconfig | 2 ++
arch/arm/boot/dts/aspeed-g5.dtsi | 16 +++++++++++++++-
drivers/gpio/Kconfig | 8 ++++++++
drivers/gpio/Makefile | 1 +
4 files changed, 26 insertions(+), 1 deletion(-)
--
2.7.4
_______________________________________________
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 v2 0/6] arm64: dts: meson-g12: add support for PCIe
From: Kevin Hilman @ 2019-09-24 18:59 UTC (permalink / raw)
To: Neil Armstrong, lorenzo.pieralisi, kishon, bhelgaas,
andrew.murray
Cc: gouwa, Neil Armstrong, linux-pci, nick, linux-kernel, yue.wang,
repk, maz, linux-amlogic, linux-arm-kernel
In-Reply-To: <20190916125022.10754-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> This patchset :
> - updates the Amlogic PCI bindings for G12A
> - reworks the Amlogic PCIe driver to make use of the
> G12a USB3+PCIe Combo PHY instead of directly writing in
> the PHY register
> - adds the necessary operations to the G12a USB3+PCIe Combo PHY driver
> - adds the PCIe Node for G12A, G12B and SM1 SoCs
> - adds the commented support for the S922X, A311D and S905D3 based
> VIM3 boards.
>
> The VIM3 schematic can be found at [1].
>
> This patchset is dependent on Remi's "Fix reset assertion via gpio descriptor"
> patch at [2].
>
> This patchset has been tested in a A311D VIM3 and S905D3 VIM3L using a
> 128Go TS128GMTE110S NVMe PCIe module.
>
> For indication, here is a bonnie++ run as ext4 formatted on the VIM3:
> ------Sequential Output------ --Sequential Input- --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
> 4G 93865 99 312837 96 194487 23 102808 97 415501 21 +++++ +++
>
> and the S905D3 VIM3L version:
> ------Sequential Output------ --Sequential Input- --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
> 4G 52144 95 71766 21 47302 10 57078 98 415469 44 +++++ +++
>
> Changes since v1 at [3]:
> - Collected Andrew's and Rob's Reviewed-by tags
> - Added missing calls to phy_init/phy_exit
> - Fixes has_shared_phy handling for MIPI clock
> - Add comment in the DT concerning firmware setting the right properties
> - Added SM1 Power Domain to PCIe node
>
> [1] https://docs.khadas.com/vim3/HardwareDocs.html
> [2] https://patchwork.kernel.org/patch/11125261/
> [3] https://patchwork.kernel.org/cover/11136927/
>
> Neil Armstrong (6):
> dt-bindings: pci: amlogic,meson-pcie: Add G12A bindings
> PCI: amlogic: Fix probed clock names
> PCI: amlogic: meson: Add support for G12A
> phy: meson-g12a-usb3-pcie: Add support for PCIe mode
> arm64: dts: meson-g12a: Add PCIe node
> arm64: dts: khadas-vim3: add commented support for PCIe
Queued the "arm64: dts" patches for v5.5,
Kevin
_______________________________________________
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 v1 1/1] i2c: iproc: Add i2c repeated start capability
From: Wolfram Sang @ 2019-09-24 18:57 UTC (permalink / raw)
To: Ray Jui
Cc: Mark Rutland, devicetree, Lori Hikichi, Florian Fainelli,
Shivaraj Shetty, Rayagonda Kokatanur, linux-kernel, Icarus Chau,
Rob Herring, bcm-kernel-feedback-list, linux-i2c,
linux-arm-kernel
In-Reply-To: <5ab79d0e-eb54-8fe1-1ca3-e763a17c6426@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 435 bytes --]
> In my opinion, it's probably better to continue to support master_xfer in
> our driver (with obvious limitations), in order to allow i2ctransfer (or any
> apps that use I2C RDWR) to continue to work.
>
> What do you think?
Yes, don't break it for users. We should have paid more attention to it
in the beginning. But, while not ideal, it is not such a big deal to
keep it like this.
Thanks for your investigations!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox