* [PATCH 2/3] arm64: dts: renesas: r8a77995: Add VIN4
From: Simon Horman @ 2018-05-15 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3456643.qNU80MrgjU@avalon>
On Mon, May 14, 2018 at 05:36:41AM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Friday, 11 May 2018 16:45:16 EEST Simon Horman wrote:
> > On Fri, May 11, 2018 at 01:25:23PM +0200, Niklas S?derlund wrote:
> > > Hi Jacopo,
> > >
> > > Thanks for your work.
> > >
> > > On 2018-05-11 12:00:01 +0200, Jacopo Mondi wrote:
> > > > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> > > >
> > > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > >
> > > Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> > >
> > >> ---
> > >>
> > >> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++++++++++
> > >> 1 file changed, 11 insertions(+)
> > >>
> > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > >> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index 82aed7e..bdf7017
> > >> 100644
> > >> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > >> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > >> @@ -783,6 +783,17 @@
> > >> };
> > >> };
> > >> };
> > >> +
> > >> + vin4: video at e6ef4000 {
> > >> + compatible = "renesas,vin-r8a77995";
> > >> + reg = <0 0xe6ef4000 0 0x1000>;
> > >> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> > >> + clocks = <&cpg CPG_MOD 807>;
> > >> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> > >> + resets = <&cpg 807>;
> > >> + renesas,id = <4>;
> > >> + status = "disabled";
> > >> + };
> > >> };
> >
> > Thanks, I have moved the new node to preserve sorting of nodes by bus
> > address and applied the result. It is as follows:
> >
> > From: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > Subject: [PATCH] arm64: dts: renesas: r8a77995: Add VIN4
> >
> > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> > [simon: sorted node by bus address]
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Thanks, tag added.
^ permalink raw reply
* [PATCH 1/4] amba: Export amba_bustype
From: Ulf Hansson @ 2018-05-15 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508140628.f30774c70c4c481bff3f8000@arm.com>
On 8 May 2018 at 21:06, Kim Phillips <kim.phillips@arm.com> wrote:
> This patch is provided in the context of allowing the Coresight driver
> subsystem to be loaded as modules. Coresight uses amba_bus in its call
> to bus_find_device() in of_coresight_get_endpoint_device() when
> searching for a configurable endpoint device. This patch allows
> Coresight to reference amba_bustype when built as a module.
Sounds like you are fixing a bug, don't your want this to go for
stable and then also add a fixes tag?
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Eric Auger <eric.auger@redhat.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Todd Kjos <tkjos@google.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
[...]
Kind regards
Uffe
^ permalink raw reply
* [PATCH] arm64: dts: fsl-ls1012a: Fix DTC aliases warnings
From: Shawn Guo @ 2018-05-15 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525694564-15203-1-git-send-email-festevam@gmail.com>
On Mon, May 07, 2018 at 09:02:44AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Use '-' instead of '_' to fix the following DTC warnings with W=1:
>
> arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dtb: Warning (alias_paths): /aliases: aliases property name must include only lowercase and '-'
>
> Cc: Harninder Rai <harninder.rai@nxp.com>
> Cc: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> Cc: Li Yang <leoyang.li@nxp.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx28-tx28: Fix alias DTC warnings
From: Shawn Guo @ 2018-05-15 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525693192-3579-1-git-send-email-festevam@gmail.com>
On Mon, May 07, 2018 at 08:39:52AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Remove underscore from alias entries to fix the following DTC warnings
> with W=1:
>
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (alias_paths): /aliases: aliases property name must include only lowercase and '-'
>
> Cc: Lothar Wa?mann <LW@KARO-electronics.de>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx28-tx28.dts | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
> index e4f19f9b..a5d6c97 100644
> --- a/arch/arm/boot/dts/imx28-tx28.dts
> +++ b/arch/arm/boot/dts/imx28-tx28.dts
> @@ -56,11 +56,11 @@
> ds1339 = &ds1339;
> gpio5 = &gpio5;
> lcdif = &lcdif;
> - lcdif_23bit_pins = &tx28_lcdif_23bit_pins;
> - lcdif_24bit_pins = &lcdif_24bit_pins_a;
> - reg_can_xcvr = ®_can_xcvr;
> - spi_gpio = &spi_gpio;
> - spi_mxs = &ssp3;
> + lcdif-23bit-pins = &tx28_lcdif_23bit_pins;
> + lcdif-24bit-pins = &lcdif_24bit_pins_a;
> + reg-can-xcvr = ®_can_xcvr;
> + spigpio = &spi_gpio;
> + spi-mxs = &ssp3;
> stk5led = &user_led;
> usbotg = &usb0;
> };
> @@ -220,7 +220,7 @@
> linux,no-autorepeat;
> };
>
> - spi_gpio: spi-gpio {
> + spi_gpio: spi {
Not sure why the node name needs to be changed here.
Shawn
> compatible = "spi-gpio";
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Richard Genoud @ 2018-05-15 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Vdcd0MmqCMGkFXcvKLrzcHtxBDcB8U1qTzysaH9By4Y8A@mail.gmail.com>
On 14/05/2018 18:56, Andy Shevchenko wrote:
> On Mon, May 14, 2018 at 1:57 PM, Richard Genoud
> <richard.genoud@gmail.com> wrote:
>> On 11/05/2018 12:38, Radu Pirea wrote:
>>> This patch modifies the place where resources and device tree properties
>>> are searched.
>
>> I think it may be simpler with something like:
>
>> + int size = mfd_pdev->resource[0].end - mfd_pdev->resource[0].start + 1;
>
> Isn't resource_size() macro for this very purpose?
Indeed.
+ int size = resource_size(mfd_pdev->resource);
would be even simpler !
>
>>> + int size = to_platform_device(pdev->dev.parent)->resource[0].end -
>>> + to_platform_device(pdev->dev.parent)->resource[0].start + 1;
>>>
>> ditto
>
> Ditto.
>
Thanks !
Richard.
^ permalink raw reply
* [GIT PULL 0/5] perf/urgent fixes
From: Ingo Molnar @ 2018-05-15 6:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514122321.27304-1-acme@kernel.org>
* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 49cf4a4b3f5a8b02556dd4f45c5cee598d4fc799:
>
> Merge tag 'perf-urgent-for-mingo-4.17-20180507' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2018-05-10 20:09:00 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.17-20180514
>
> for you to fetch changes up to c23080a6e4e853cff2834436e3cf33eae7723900:
>
> perf tools: Add missing newline when parsing empty BPF proggie (2018-05-11 12:10:02 -0300)
>
> ----------------------------------------------------------------
> perf/urgent fixes:
>
> - Fix segfault when processing unknown threads in cs-etm (Leo Yan)
>
> - Fix "perf test inet_pton" on s390 failing due to missing inline (Thomas Richter)
>
> - Display all available events on 'perf annotate --stdio' (Jin Yao)
>
> - Add missing newline when parsing empty BPF proggie (Arnaldo Carvalho de Melo)
>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> ----------------------------------------------------------------
> Arnaldo Carvalho de Melo (1):
> perf tools: Add missing newline when parsing empty BPF proggie
>
> Jin Yao (1):
> perf annotate: Display all available events on --stdio
>
> Leo Yan (2):
> perf cs-etm: Support unknown_thread in cs_etm_auxtrace
> perf cs-etm: Remove redundant space
>
> Thomas Richter (1):
> perf test: "probe libc's inet_pton" fails on s390 due to missing inline
>
> .../tests/shell/record+probe_libc_inet_pton.sh | 2 +-
> tools/perf/util/annotate.c | 3 +++
> tools/perf/util/cs-etm.c | 28 ++++++++++++++++++----
> tools/perf/util/parse-events.c | 2 +-
> 4 files changed, 29 insertions(+), 6 deletions(-)
Pulled, thanks a lot Arnaldo!
Ingo
^ permalink raw reply
* linux-next: manual merge of the samsung-krzk tree with the dma-mapping tree
From: Krzysztof Kozlowski @ 2018-05-15 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515090901.74c9429e@canb.auug.org.au>
On Tue, May 15, 2018 at 1:09 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Thu, 10 May 2018 09:16:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the samsung-krzk tree got a conflict in:
>>
>> arch/arm/mach-exynos/Kconfig
>>
>> between commit:
>>
>> 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig")
>>
>> from the dma-mapping tree and commit:
>>
>> c5deb598089c ("ARM: exynos: Remove support for Exynos5440")
>>
>> from the samsung-krzk tree.
>>
>> I fixed it up (the latter removed the whole section modified by
>> the former, so I just removed the section) and can carry the fix as
>> necessary. This is now fixed as far as linux-next is concerned, but any
>> non trivial conflicts should be mentioned to your upstream maintainer
>> when your tree is submitted for merging. You may also want to consider
>> cooperating with the maintainer of the conflicting tree to minimise any
>> particularly complex conflicts.
>
> This is now a conflict between the arm-soc tree and the dma-mapping tree.
Yes, this is expected. Thanks for letting us know. I mentioned this
also in my pull request to arm-soc.
Best regards,
Krzysztof
^ permalink raw reply
* [GIT PULL 0/5] ARM: samsung/exynos: Stuff for v4.18
From: Krzysztof Kozlowski @ 2018-05-15 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514205502.u25kugxkym4tz34e@localhost>
On Mon, May 14, 2018 at 10:55 PM, Olof Johansson <olof@lixom.net> wrote:
> On Sun, May 13, 2018 at 05:42:33PM +0200, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> Changes for v4.18. No dependencies, no specific order of pulls.
>>
>> Support for Exynos5440 is removed step by step through different trees.
>
> 5440 was always a bit of a weird fit, it clearly was never an exynos5-family
> platform. I take it there are no substantial users left that would need
> mainline kernel support for it?
I forgot to mention this in pull request (it is in the commit) - there
are no known users. There are no real products and development boards
are unpopular (probably only Samsung LSI has it).
> Also, I noticed your PGP key has expired, so you should probably start
> collecting signatures on a fresh subkey.
It should be good, I prolonged it some time ago. Can you refresh it in
your keyring?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: berlin2q: add "cache-unified" to l2 node
From: Jisheng Zhang @ 2018-05-15 6:05 UTC (permalink / raw)
To: linux-arm-kernel
Without this property, we get this boot warning:
"L2C: device tree omits to specify unified cache"
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm/boot/dts/berlin2q.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index e23c49ae3ec2..7cba798152b9 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -149,6 +149,7 @@
l2: l2-cache-controller at ac0000 {
compatible = "arm,pl310-cache";
reg = <0xac0000 0x1000>;
+ cache-unified;
cache-level = <2>;
arm,data-latency = <2 2 2>;
arm,tag-latency = <2 2 2>;
--
2.17.0
^ permalink raw reply related
* [PATCH] ARM: dts: chromecast: override bad bootloader memory info
From: Tom Hebb @ 2018-05-15 6:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515102939.3ab8797c@xhacker.debian>
Hi,
On 05/14/2018 10:29 PM, Jisheng Zhang wrote:
> Hi,
>
> On Mon, 14 May 2018 17:56:45 -0400 Thomas Hebb wrote:
>
>> On the Chromecast, the bootloader provides us with an ATAG_MEM of
>> start=0x01000000 and size=0x3eff8000. This is clearly incorrect, as the
>> range given encompasses nearly a GiB but the Chromecast only has 512MiB
>> of RAM! Additionally, this causes the kernel to be decompressed at
>> 0x00008000, below the claimed beginning of RAM, and so the boot fails.
>>
>> Since the existing ATAG parsing code runs before the kernel is even
>> decompressed and irrevocably patches the device tree, don't even try
>
> This means you enabled ARM_ATAG_DTB_COMPAT. could we disable it instead?
> The ATAG is useless when we provide dtb. And IIRC, the ATAG is provided due
> to legacy history code.
>
> Thanks
Thanks for the quick review! It's true that compiling without
ARM_ATAG_DTB_COMPAT will prevent ATAG_MEM from getting parsed at all.
However, it will also prevent ATAG_CMDLINE from getting parsed, and the
command line from the Chromecast's bootloader does actually contain some
useful information--notably the mode in which the system was booted
(normal or recovery).
Userspace could conceivably want this information, so it's preferable
for the kernel to boot regardless of whether ARM_ATAG_DTB_COMPAT is
enabled. That's the intent of this patch.
I do agree in principle that ARM_ATAG_DTB_COMPAT should be disabled
whenever possible.
>> to bypass it. Instead, use the "linux,usable-memory" property instead
>> of the "reg" property to define the real range. The ATAG code only
>> overwrites reg, but linux,usable-memory is checked first in the OF
>> driver, so the fact that reg gets changed makes no difference.
>>
>> Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
>> ---
>> arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> index 20f31cdeaf38..54221f55bfa2 100644
>> --- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> @@ -52,7 +52,17 @@
>>
>> memory at 0 {
>> device_type = "memory";
>> - reg = <0x00000000 0x20000000>; /* 512 MB */
>> +
>> + /*
>> + * We're using "linux,usable-memory" instead of "reg" here
>> + * because the (signed and encrypted) bootloader that shipped
>> + * with this device provides an incorrect memory range in
>> + * ATAG_MEM. Linux helpfully overrides the "reg" property with
>> + * data from the ATAG, so we can't specify the proper range
>> + * normally. Fortunately, this alternate property is checked
>> + * first by the OF driver, so we can (ab)use it instead.
>> + */
>> + linux,usable-memory = <0x00000000 0x20000000>; /* 512 MB */
>> };
>>
>> leds {
>
^ permalink raw reply
* [PATCH v3 8/8] PCI: Enable PCI_DOMAINS along with generic PCI host controller
From: Jan Kiszka @ 2018-05-15 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526363896.git.jan.kiszka@siemens.com>
From: Jan Kiszka <jan.kiszka@siemens.com>
This controller is often instantiated by hypervisors, and they may add
multiple of them or add them in addition to a physical host controller
like the Jailhouse hypervisor is doing. Therefore allow for multiple
domains so that we can handle them all.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/pci/host/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 0d0177ce436c..3d25b35bb5ab 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -68,6 +68,7 @@ config PCI_HOST_GENERIC
depends on (ARM || ARM64) && OF
select PCI_HOST_COMMON
select IRQ_DOMAIN
+ select PCI_DOMAINS
help
Say Y here if you want to support a simple generic PCI host
controller, such as the one emulated by kvmtool.
--
2.13.6
^ permalink raw reply related
* [PATCH v3 7/8] PCI: Add support for unbinding the generic PCI host controller
From: Jan Kiszka @ 2018-05-15 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526363896.git.jan.kiszka@siemens.com>
From: Jan Kiszka <jan.kiszka@siemens.com>
Particularly useful when working in virtual environments where the
controller may come and go, but possibly not only there.
CC: Will Deacon <will.deacon@arm.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/pci/host/pci-host-common.c | 13 +++++++++++++
drivers/pci/host/pci-host-generic.c | 1 +
include/linux/pci-ecam.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/drivers/pci/host/pci-host-common.c b/drivers/pci/host/pci-host-common.c
index 5d028f53fdcd..d8f10451f273 100644
--- a/drivers/pci/host/pci-host-common.c
+++ b/drivers/pci/host/pci-host-common.c
@@ -101,5 +101,18 @@ int pci_host_common_probe(struct platform_device *pdev,
return ret;
}
+ platform_set_drvdata(pdev, bridge->bus);
+ return 0;
+}
+
+int pci_host_common_remove(struct platform_device *pdev)
+{
+ struct pci_bus *bus = platform_get_drvdata(pdev);
+
+ pci_lock_rescan_remove();
+ pci_stop_root_bus(bus);
+ pci_remove_root_bus(bus);
+ pci_unlock_rescan_remove();
+
return 0;
}
diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
index 45319ee3b484..dea3ec7592a2 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -95,5 +95,6 @@ static struct platform_driver gen_pci_driver = {
.suppress_bind_attrs = true,
},
.probe = gen_pci_probe,
+ .remove = pci_host_common_remove,
};
builtin_platform_driver(gen_pci_driver);
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index baadad1aabbc..29efa09d686b 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -62,5 +62,6 @@ extern struct pci_ecam_ops xgene_v2_pcie_ecam_ops; /* APM X-Gene PCIe v2.x */
/* for DT-based PCI controllers that support ECAM */
int pci_host_common_probe(struct platform_device *pdev,
struct pci_ecam_ops *ops);
+int pci_host_common_remove(struct platform_device *pdev);
#endif
#endif
--
2.13.6
^ permalink raw reply related
* [PATCH v3 6/8] PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()
From: Jan Kiszka @ 2018-05-15 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526363896.git.jan.kiszka@siemens.com>
From: Jan Kiszka <jan.kiszka@siemens.com>
of_pci_get_host_bridge_resources() allocates the resource structures it
fills dynamically, but none of its callers care to release them so far.
Rather than requiring everyone to do this explicitly, convert the
existing function to a managed version.
CC: Jingoo Han <jingoohan1@gmail.com>
CC: Joao Pinto <Joao.Pinto@synopsys.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/pci/dwc/pcie-designware-host.c | 2 +-
drivers/pci/host/pci-aardvark.c | 2 +-
drivers/pci/host/pci-ftpci100.c | 2 +-
drivers/pci/host/pci-v3-semi.c | 2 +-
drivers/pci/host/pci-versatile.c | 2 +-
drivers/pci/host/pci-xgene.c | 2 +-
drivers/pci/host/pcie-altera.c | 2 +-
drivers/pci/host/pcie-iproc-platform.c | 2 +-
drivers/pci/host/pcie-rcar.c | 2 +-
drivers/pci/host/pcie-rockchip.c | 2 +-
drivers/pci/host/pcie-xilinx-nwl.c | 2 +-
drivers/pci/host/pcie-xilinx.c | 2 +-
drivers/pci/of.c | 37 +++++++++++-----------------------
include/linux/of_pci.h | 4 ++--
14 files changed, 26 insertions(+), 39 deletions(-)
diff --git a/drivers/pci/dwc/pcie-designware-host.c b/drivers/pci/dwc/pcie-designware-host.c
index 5a535690b7b5..a8f6ab54b4c0 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (!bridge)
return -ENOMEM;
- ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
&bridge->windows, &pp->io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index 39d8fc2a8a76..1e048dd806dc 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -827,7 +827,7 @@ static int advk_pcie_parse_request_of_pci_ranges(struct advk_pcie *pcie)
INIT_LIST_HEAD(&pcie->resources);
- err = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
&pcie->resources, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-ftpci100.c
index 5c176f806fe5..87748eaeaaed 100644
--- a/drivers/pci/host/pci-ftpci100.c
+++ b/drivers/pci/host/pci-ftpci100.c
@@ -476,7 +476,7 @@ static int faraday_pci_probe(struct platform_device *pdev)
if (IS_ERR(p->base))
return PTR_ERR(p->base);
- ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
&res, &io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-semi.c
index f3f39935ac2f..167bf6f6b378 100644
--- a/drivers/pci/host/pci-v3-semi.c
+++ b/drivers/pci/host/pci-v3-semi.c
@@ -791,7 +791,7 @@ static int v3_pci_probe(struct platform_device *pdev)
if (IS_ERR(v3->config_base))
return PTR_ERR(v3->config_base);
- ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
&io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
index ef33ec0a9e1b..ff2cd12b3978 100644
--- a/drivers/pci/host/pci-versatile.c
+++ b/drivers/pci/host/pci-versatile.c
@@ -67,7 +67,7 @@ static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
resource_size_t iobase;
struct resource_entry *win, *tmp;
- err = of_pci_get_host_bridge_resources(dev, 0, 0xff, res, &iobase);
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, res, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 88e9a6d315b3..7b3ed6e34b6c 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -632,7 +632,7 @@ static int xgene_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
&iobase);
if (ret)
return ret;
diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
index 61802e55a00c..49410c7ba0cc 100644
--- a/drivers/pci/host/pcie-altera.c
+++ b/drivers/pci/host/pcie-altera.c
@@ -490,7 +490,7 @@ static int altera_pcie_parse_request_of_pci_ranges(struct altera_pcie *pcie)
struct device *dev = &pcie->pdev->dev;
struct resource_entry *win;
- err = of_pci_get_host_bridge_resources(dev, 0, 0xff
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff
&pcie->resources, NULL);
if (err)
return err;
diff --git a/drivers/pci/host/pcie-iproc-platform.c b/drivers/pci/host/pcie-iproc-platform.c
index cec0130326c9..99c2022813e4 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -99,7 +99,7 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev)
pcie->phy = NULL;
}
- ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &resources,
+ ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &resources,
&iobase);
if (ret) {
dev_err(dev, "unable to get PCI host bridge resources\n");
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 4c1787e021fd..6eb36c924983 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -1070,7 +1070,7 @@ static int rcar_pcie_parse_request_of_pci_ranges(struct rcar_pcie *pci)
resource_size_t iobase;
struct resource_entry *win, *tmp;
- err = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
&pci->resources, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index abac972f0dc2..27b97fcddf15 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -1560,7 +1560,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
if (err < 0)
goto err_deinit_port;
- err = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
&res, &io_base);
if (err)
goto err_remove_irq_domain;
diff --git a/drivers/pci/host/pcie-xilinx-nwl.c b/drivers/pci/host/pcie-xilinx-nwl.c
index 6aea997cd21b..64df768c795c 100644
--- a/drivers/pci/host/pcie-xilinx-nwl.c
+++ b/drivers/pci/host/pcie-xilinx-nwl.c
@@ -854,7 +854,7 @@ static int nwl_pcie_probe(struct platform_device *pdev)
return err;
}
- err = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
&iobase);
if (err) {
dev_err(dev, "Getting bridge resources failed\n");
diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index fa5e44a480a4..88c96e5669e0 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -643,7 +643,7 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
return err;
}
- err = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
&iobase);
if (err) {
dev_err(dev, "Getting bridge resources failed\n");
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 4f21514cb4e4..00f42389aa56 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -244,7 +244,8 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
#if defined(CONFIG_OF_ADDRESS)
/**
- * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
+ * devm_of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI
+ * host bridge resources from DT
* @dev: host bridge device
* @busno: bus number associated with the bridge root bus
* @bus_max: maximum number of buses for this bridge
@@ -253,8 +254,6 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
* address for the start of the I/O range. Can be NULL if the caller doesn't
* expect I/O ranges to be present in the device tree.
*
- * It is the caller's job to free the @resources list.
- *
* This function will parse the "ranges" property of a PCI host bridge device
* node and setup the resource mapping based on its content. It is expected
* that the property conforms with the Power ePAPR document.
@@ -262,12 +261,11 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
* It returns zero if the range parsing has been successful or a standard error
* value if it failed.
*/
-int of_pci_get_host_bridge_resources(struct device *dev,
+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 device_node *dev_node = dev->of_node;
- struct resource_entry *window;
struct resource *res;
struct resource *bus_range;
struct of_pci_range range;
@@ -278,7 +276,7 @@ int of_pci_get_host_bridge_resources(struct device *dev,
if (io_base)
*io_base = (resource_size_t)OF_BAD_ADDR;
- bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
+ bus_range = devm_kzalloc(dev, sizeof(*bus_range), GFP_KERNEL);
if (!bus_range)
return -ENOMEM;
@@ -300,7 +298,7 @@ int of_pci_get_host_bridge_resources(struct device *dev,
/* Check for ranges property */
err = of_pci_range_parser_init(&parser, dev_node);
if (err)
- goto parse_failed;
+ return err;
dev_dbg(dev, "Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
@@ -322,15 +320,13 @@ int of_pci_get_host_bridge_resources(struct device *dev,
if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;
- res = kzalloc(sizeof(struct resource), GFP_KERNEL);
- if (!res) {
- err = -ENOMEM;
- goto parse_failed;
- }
+ res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL);
+ if (!res)
+ return -ENOMEM;
err = of_pci_range_to_resource(&range, dev_node, res);
if (err) {
- kfree(res);
+ devm_kfree(dev, res);
continue;
}
@@ -339,8 +335,7 @@ int of_pci_get_host_bridge_resources(struct device *dev,
dev_err(dev,
"I/O range found for %pOF. Please provide an io_base pointer to save CPU base address\n",
dev_node);
- err = -EINVAL;
- goto conversion_failed;
+ return -EINVAL;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
dev_warn(dev,
@@ -353,16 +348,8 @@ int of_pci_get_host_bridge_resources(struct device *dev,
}
return 0;
-
-conversion_failed:
- kfree(res);
-parse_failed:
- resource_list_for_each_entry(window, resources)
- kfree(window->res);
- pci_free_resource_list(resources);
- return err;
}
-EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+EXPORT_SYMBOL_GPL(devm_of_pci_get_host_bridge_resources);
#endif /* CONFIG_OF_ADDRESS */
/**
@@ -606,7 +593,7 @@ int pci_parse_request_of_pci_ranges(struct device *dev,
struct resource_entry *win, *tmp;
INIT_LIST_HEAD(resources);
- err = of_pci_get_host_bridge_resources(dev, 0, 0xff, resources,
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, resources,
&iobase);
if (err)
return err;
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index e6684c68cb94..fa4463a52900 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -71,11 +71,11 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin)
#endif
#if defined(CONFIG_OF_ADDRESS)
-int of_pci_get_host_bridge_resources(struct device *dev,
+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);
#else
-static inline int of_pci_get_host_bridge_resources(struct device *dev,
+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)
{
--
2.13.6
^ permalink raw reply related
* [PATCH v3 5/8] PCI: Replace pr_*() with dev_*() in of_pci_get_host_bridge_resources()
From: Jan Kiszka @ 2018-05-15 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526363896.git.jan.kiszka@siemens.com>
From: Jan Kiszka <jan.kiszka@siemens.com>
Now that we have a device reference, make use of it for printing.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/pci/of.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index ac97491ba377..4f21514cb4e4 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -282,15 +282,15 @@ int of_pci_get_host_bridge_resources(struct device *dev,
if (!bus_range)
return -ENOMEM;
- pr_info("host bridge %pOF ranges:\n", dev_node);
+ dev_info(dev, "host bridge %pOF ranges:\n", dev_node);
err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
- pr_info(" No bus range found for %pOF, using %pR\n",
- dev_node, bus_range);
+ dev_info(dev, " No bus range found for %pOF, using %pR\n",
+ dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -302,7 +302,7 @@ int of_pci_get_host_bridge_resources(struct device *dev,
if (err)
goto parse_failed;
- pr_debug("Parsing ranges property...\n");
+ dev_dbg(dev, "Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
@@ -311,9 +311,9 @@ int of_pci_get_host_bridge_resources(struct device *dev,
snprintf(range_type, 4, "MEM");
else
snprintf(range_type, 4, "err");
- pr_info(" %s %#010llx..%#010llx -> %#010llx\n", range_type,
- range.cpu_addr, range.cpu_addr + range.size - 1,
- range.pci_addr);
+ dev_info(dev, " %s %#010llx..%#010llx -> %#010llx\n",
+ range_type, range.cpu_addr,
+ range.cpu_addr + range.size - 1, range.pci_addr);
/*
* If we failed translation or got a zero-sized region
@@ -336,14 +336,16 @@ int of_pci_get_host_bridge_resources(struct device *dev,
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
- pr_err("I/O range found for %pOF. Please provide an io_base pointer to save CPU base address\n",
+ dev_err(dev,
+ "I/O range found for %pOF. Please provide an io_base pointer to save CPU base address\n",
dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
- pr_warn("More than one I/O resource converted for %pOF. CPU base address for old range lost!\n",
- dev_node);
+ dev_warn(dev,
+ "More than one I/O resource converted for %pOF. CPU base address for old range lost!\n",
+ dev_node);
*io_base = range.cpu_addr;
}
--
2.13.6
^ permalink raw reply related
* [PATCH v3 4/8] PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources with device
From: Jan Kiszka @ 2018-05-15 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526363896.git.jan.kiszka@siemens.com>
From: Jan Kiszka <jan.kiszka@siemens.com>
Another step towards a managed version of
of_pci_get_host_bridge_resources(): Feed in the underlying device,
rather than just the OF node. This will allow to use managed resource
allocation internally later on.
CC: Jingoo Han <jingoohan1@gmail.com>
CC: Joao Pinto <Joao.Pinto@synopsys.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/pci/dwc/pcie-designware-host.c | 2 +-
drivers/pci/host/pci-aardvark.c | 5 ++---
drivers/pci/host/pci-ftpci100.c | 4 ++--
drivers/pci/host/pci-v3-semi.c | 3 ++-
drivers/pci/host/pci-versatile.c | 3 +--
drivers/pci/host/pci-xgene.c | 3 ++-
drivers/pci/host/pcie-altera.c | 5 ++---
drivers/pci/host/pcie-iproc-platform.c | 4 ++--
drivers/pci/host/pcie-rcar.c | 5 ++---
drivers/pci/host/pcie-rockchip.c | 4 ++--
drivers/pci/host/pcie-xilinx-nwl.c | 4 ++--
drivers/pci/host/pcie-xilinx.c | 4 ++--
drivers/pci/of.c | 9 +++++----
include/linux/of_pci.h | 4 ++--
14 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/pci/dwc/pcie-designware-host.c b/drivers/pci/dwc/pcie-designware-host.c
index 6c409079d514..5a535690b7b5 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (!bridge)
return -ENOMEM;
- ret = of_pci_get_host_bridge_resources(np, 0, 0xff,
+ ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
&bridge->windows, &pp->io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index 9abf549631b4..39d8fc2a8a76 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -822,14 +822,13 @@ 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 device_node *np = dev->of_node;
struct resource_entry *win, *tmp;
resource_size_t iobase;
INIT_LIST_HEAD(&pcie->resources);
- err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pcie->resources,
- &iobase);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ &pcie->resources, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-ftpci100.c
index 5008fd87956a..5c176f806fe5 100644
--- a/drivers/pci/host/pci-ftpci100.c
+++ b/drivers/pci/host/pci-ftpci100.c
@@ -476,8 +476,8 @@ static int faraday_pci_probe(struct platform_device *pdev)
if (IS_ERR(p->base))
return PTR_ERR(p->base);
- ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
- &res, &io_base);
+ ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ &res, &io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-semi.c
index 0a4dea796663..f3f39935ac2f 100644
--- a/drivers/pci/host/pci-v3-semi.c
+++ b/drivers/pci/host/pci-v3-semi.c
@@ -791,7 +791,8 @@ static int v3_pci_probe(struct platform_device *pdev)
if (IS_ERR(v3->config_base))
return PTR_ERR(v3->config_base);
- ret = of_pci_get_host_bridge_resources(np, 0, 0xff, &res, &io_base);
+ ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ &io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
index 5b3876f5312b..ef33ec0a9e1b 100644
--- a/drivers/pci/host/pci-versatile.c
+++ b/drivers/pci/host/pci-versatile.c
@@ -64,11 +64,10 @@ static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
struct list_head *res)
{
int err, mem = 1, res_valid = 0;
- struct device_node *np = dev->of_node;
resource_size_t iobase;
struct resource_entry *win, *tmp;
- err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff, res, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 0a0d7ee6d3c9..88e9a6d315b3 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -632,7 +632,8 @@ static int xgene_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = of_pci_get_host_bridge_resources(dn, 0, 0xff, &res, &iobase);
+ ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ &iobase);
if (ret)
return ret;
diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
index a6af62e0256d..61802e55a00c 100644
--- a/drivers/pci/host/pcie-altera.c
+++ b/drivers/pci/host/pcie-altera.c
@@ -488,11 +488,10 @@ 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 device_node *np = dev->of_node;
struct resource_entry *win;
- err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pcie->resources,
- NULL);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff
+ &pcie->resources, NULL);
if (err)
return err;
diff --git a/drivers/pci/host/pcie-iproc-platform.c b/drivers/pci/host/pcie-iproc-platform.c
index e764a2a2693c..cec0130326c9 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -99,8 +99,8 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev)
pcie->phy = NULL;
}
- ret = of_pci_get_host_bridge_resources(np, 0, 0xff, &resources,
- &iobase);
+ ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &resources,
+ &iobase);
if (ret) {
dev_err(dev, "unable to get PCI host bridge resources\n");
return ret;
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 6ab28f29ac6a..4c1787e021fd 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -1067,12 +1067,11 @@ static int rcar_pcie_parse_request_of_pci_ranges(struct rcar_pcie *pci)
{
int err;
struct device *dev = pci->dev;
- struct device_node *np = dev->of_node;
resource_size_t iobase;
struct resource_entry *win, *tmp;
- err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pci->resources,
- &iobase);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ &pci->resources, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index f1e8f97ea1fb..abac972f0dc2 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -1560,8 +1560,8 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
if (err < 0)
goto err_deinit_port;
- err = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
- &res, &io_base);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ &res, &io_base);
if (err)
goto err_remove_irq_domain;
diff --git a/drivers/pci/host/pcie-xilinx-nwl.c b/drivers/pci/host/pcie-xilinx-nwl.c
index 4839ae578711..6aea997cd21b 100644
--- a/drivers/pci/host/pcie-xilinx-nwl.c
+++ b/drivers/pci/host/pcie-xilinx-nwl.c
@@ -825,7 +825,6 @@ static const struct of_device_id nwl_pcie_of_match[] = {
static int nwl_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct device_node *node = dev->of_node;
struct nwl_pcie *pcie;
struct pci_bus *bus;
struct pci_bus *child;
@@ -855,7 +854,8 @@ static int nwl_pcie_probe(struct platform_device *pdev)
return err;
}
- err = of_pci_get_host_bridge_resources(node, 0, 0xff, &res, &iobase);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ &iobase);
if (err) {
dev_err(dev, "Getting bridge resources failed\n");
return err;
diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 0ad188effc09..fa5e44a480a4 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -643,8 +643,8 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
return err;
}
- err = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff, &res,
- &iobase);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ &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 8d4778ef5806..ac97491ba377 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -245,7 +245,7 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
#if defined(CONFIG_OF_ADDRESS)
/**
* of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
- * @dev_node: device node of the host bridge having the range property
+ * @dev: host bridge device
* @busno: bus number associated with the bridge root bus
* @bus_max: maximum number of buses for this bridge
* @resources: list where the range of resources will be added after DT parsing
@@ -262,10 +262,11 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
* It returns zero if the range parsing has been successful or a standard error
* value if it failed.
*/
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
+int 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 device_node *dev_node = dev->of_node;
struct resource_entry *window;
struct resource *res;
struct resource *bus_range;
@@ -599,12 +600,12 @@ int pci_parse_request_of_pci_ranges(struct device *dev,
struct resource **bus_range)
{
int err, res_valid = 0;
- struct device_node *np = dev->of_node;
resource_size_t iobase;
struct resource_entry *win, *tmp;
INIT_LIST_HEAD(resources);
- err = of_pci_get_host_bridge_resources(np, 0, 0xff, resources, &iobase);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff, resources,
+ &iobase);
if (err)
return err;
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 74eec1943ad2..e6684c68cb94 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -71,11 +71,11 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin)
#endif
#if defined(CONFIG_OF_ADDRESS)
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
+int 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);
#else
-static inline int of_pci_get_host_bridge_resources(struct device_node *dev_node,
+static inline int 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)
{
--
2.13.6
^ permalink raw reply related
* [PATCH v3 3/8] PCI: Rename device node parameter of of_pci_get_host_bridge_resources()
From: Jan Kiszka @ 2018-05-15 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526363896.git.jan.kiszka@siemens.com>
From: Jan Kiszka <jan.kiszka@siemens.com>
We will add a real device parameter to this function soon.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/pci/of.c | 18 +++++++++---------
include/linux/of_pci.h | 4 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c273ae..8d4778ef5806 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -245,7 +245,7 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
#if defined(CONFIG_OF_ADDRESS)
/**
* of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
- * @dev: device node of the host bridge having the range property
+ * @dev_node: device node of the host bridge having the range property
* @busno: bus number associated with the bridge root bus
* @bus_max: maximum number of buses for this bridge
* @resources: list where the range of resources will be added after DT parsing
@@ -262,7 +262,7 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
* It returns zero if the range parsing has been successful or a standard error
* value if it failed.
*/
-int of_pci_get_host_bridge_resources(struct device_node *dev,
+int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
{
@@ -281,15 +281,15 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
if (!bus_range)
return -ENOMEM;
- pr_info("host bridge %pOF ranges:\n", dev);
+ pr_info("host bridge %pOF ranges:\n", dev_node);
- err = of_pci_parse_bus_range(dev, bus_range);
+ err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
pr_info(" No bus range found for %pOF, using %pR\n",
- dev, bus_range);
+ dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -297,7 +297,7 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
pci_add_resource(resources, bus_range);
/* Check for ranges property */
- err = of_pci_range_parser_init(&parser, dev);
+ err = of_pci_range_parser_init(&parser, dev_node);
if (err)
goto parse_failed;
@@ -327,7 +327,7 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
goto parse_failed;
}
- err = of_pci_range_to_resource(&range, dev, res);
+ err = of_pci_range_to_resource(&range, dev_node, res);
if (err) {
kfree(res);
continue;
@@ -336,13 +336,13 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
pr_err("I/O range found for %pOF. Please provide an io_base pointer to save CPU base address\n",
- dev);
+ dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
pr_warn("More than one I/O resource converted for %pOF. CPU base address for old range lost!\n",
- dev);
+ dev_node);
*io_base = range.cpu_addr;
}
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 091033a6b836..74eec1943ad2 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -71,11 +71,11 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin)
#endif
#if defined(CONFIG_OF_ADDRESS)
-int of_pci_get_host_bridge_resources(struct device_node *dev,
+int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
#else
-static inline int of_pci_get_host_bridge_resources(struct device_node *dev,
+static inline int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
{
--
2.13.6
^ permalink raw reply related
* [PATCH v3 2/8] PCI: Fix memory leak of devm_pci_alloc_host_bridge()
From: Jan Kiszka @ 2018-05-15 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526363896.git.jan.kiszka@siemens.com>
From: Jan Kiszka <jan.kiszka@siemens.com>
devm_pci_release_host_bridge_dev() failed to release the resource list.
Fixes: 5c3f18cce083 ("PCI: Add devm_pci_alloc_host_bridge() interface")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/pci/probe.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac91b6fd0bcd..eccf204c9160 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -526,12 +526,14 @@ static void devm_pci_release_host_bridge_dev(struct device *dev)
if (bridge->release_fn)
bridge->release_fn(bridge);
+
+ pci_free_resource_list(&bridge->windows);
}
static void pci_release_host_bridge_dev(struct device *dev)
{
devm_pci_release_host_bridge_dev(dev);
- pci_free_host_bridge(to_pci_host_bridge(dev));
+ kfree(to_pci_host_bridge(dev));
}
struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
--
2.13.6
^ permalink raw reply related
* [PATCH v3 1/8] PCI: Make pci_get_new_domain_nr() static
From: Jan Kiszka @ 2018-05-15 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526363896.git.jan.kiszka@siemens.com>
From: Jan Kiszka <jan.kiszka@siemens.com>
The only user of pci_get_new_domain_nr() is of_pci_bus_find_domain_nr().
Since they are defined in the same compilation unit,
pci_get_new_domain_nr() can be made static, which also simplifies
preprocessor conditionals.
No functional change intended.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
drivers/pci/pci.c | 6 ++----
include/linux/pci.h | 3 ---
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index dbfe7c4f3776..fe28cd76eacd 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5719,15 +5719,14 @@ static void pci_no_domains(void)
#endif
}
-#ifdef CONFIG_PCI_DOMAINS
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
static atomic_t __domain_nr = ATOMIC_INIT(-1);
-int pci_get_new_domain_nr(void)
+static int pci_get_new_domain_nr(void)
{
return atomic_inc_return(&__domain_nr);
}
-#ifdef CONFIG_PCI_DOMAINS_GENERIC
static int of_pci_bus_find_domain_nr(struct device *parent)
{
static int use_dt_domains = -1;
@@ -5782,7 +5781,6 @@ int pci_bus_find_domain_nr(struct pci_bus *bus, struct device *parent)
acpi_pci_bus_find_domain_nr(bus);
}
#endif
-#endif
/**
* pci_ext_cfg_avail - can we access extended PCI config space?
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 73178a2fcee0..963232a6cd2e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1510,12 +1510,10 @@ void pci_cfg_access_unlock(struct pci_dev *dev);
*/
#ifdef CONFIG_PCI_DOMAINS
extern int pci_domains_supported;
-int pci_get_new_domain_nr(void);
#else
enum { pci_domains_supported = 0 };
static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
#endif /* CONFIG_PCI_DOMAINS */
/*
@@ -1670,7 +1668,6 @@ static inline struct pci_dev *pci_get_domain_bus_and_slot(int domain,
static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
#define dev_is_pci(d) (false)
#define dev_is_pf(d) (false)
--
2.13.6
^ permalink raw reply related
* [PATCH v3 0/8] PCI: leak fixes, removable generic PCI host, assorted stuff
From: Jan Kiszka @ 2018-05-15 5:58 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v3:
- refactor series to be both bisectable and simpler while reworking
of_pci_get_host_bridge_resources()
- include of_pci_get_host_bridge_resources() removal
- include devm_of_pci_get_host_bridge_resources() error path fixes
- effectively, no functional changes to v2
Changes in v2:
- patch 1: commit message reworking as suggested by Lorenzo
- patch 3-6: split-up as suggested by Bjorn
- patch 8: new
- patch 10: select PCI_DOMAINS from PCI_HOST_GENERIC, rather than
allowing manual choice, as suggested by Lorenzo
This primarily enables to unbind the generic PCI host controller without
leaving lots of memory leaks behind. A previous proposal patch 5 was
rejected because of those issues [1].
The fixes have been validated in the Jailhouse setup, where we add and
remove a virtual PCI host controller on hypervisor activation/
deactivation, with the help of kmemleak.
Besides that, there is tiny PCI API cleanup at the beginning and
support for manually enabled PCI domains at the end that enables the
Jailhouse scenario.
Jan
[1] http://lkml.iu.edu/hypermail/linux/kernel/1606.3/00072.html
CC: Jingoo Han <jingoohan1@gmail.com>
CC: Joao Pinto <Joao.Pinto@synopsys.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
CC: Will Deacon <will.deacon@arm.com>
Jan Kiszka (8):
PCI: Make pci_get_new_domain_nr() static
PCI: Fix memory leak of devm_pci_alloc_host_bridge()
PCI: Rename device node parameter of
of_pci_get_host_bridge_resources()
PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources
with device
PCI: Replace pr_*() with dev_*() in of_pci_get_host_bridge_resources()
PCI: Rework of_pci_get_host_bridge_resources() to
devm_of_pci_get_host_bridge_resources()
PCI: Add support for unbinding the generic PCI host controller
PCI: Enable PCI_DOMAINS along with generic PCI host controller
drivers/pci/dwc/pcie-designware-host.c | 2 +-
drivers/pci/host/Kconfig | 1 +
drivers/pci/host/pci-aardvark.c | 5 +--
drivers/pci/host/pci-ftpci100.c | 4 +-
drivers/pci/host/pci-host-common.c | 13 ++++++
drivers/pci/host/pci-host-generic.c | 1 +
drivers/pci/host/pci-v3-semi.c | 3 +-
drivers/pci/host/pci-versatile.c | 3 +-
drivers/pci/host/pci-xgene.c | 3 +-
drivers/pci/host/pcie-altera.c | 5 +--
drivers/pci/host/pcie-iproc-platform.c | 4 +-
drivers/pci/host/pcie-rcar.c | 5 +--
drivers/pci/host/pcie-rockchip.c | 4 +-
drivers/pci/host/pcie-xilinx-nwl.c | 4 +-
drivers/pci/host/pcie-xilinx.c | 4 +-
drivers/pci/of.c | 72 +++++++++++++++-------------------
drivers/pci/pci.c | 6 +--
drivers/pci/probe.c | 4 +-
include/linux/of_pci.h | 4 +-
include/linux/pci-ecam.h | 1 +
include/linux/pci.h | 3 --
21 files changed, 76 insertions(+), 75 deletions(-)
--
2.13.6
^ permalink raw reply
* [PATCH 1/2] ARM64: dts: meson-gxbb: odroidc2: enable sdcard UHS modes
From: Anand Moon @ 2018-05-15 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526305693.2897.16.camel@baylibre.com>
Hi Jerome
On 14 May 2018 at 19:18, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Wed, 2018-05-02 at 00:29 +0530, Anand Moon wrote:
>> Enable UHS modes for sdcard, on odroidc2.
>>
>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> index 54954b314a45..c90f8b46c60c 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> @@ -258,6 +258,11 @@
>> cap-sd-highspeed;
>> max-frequency = <100000000>;
>> disable-wp;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> + sd-uhs-ddr50;
>>
>> cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
>> cd-inverted;
>
> Hi Anand,
>
> I tried a few sdcards on the OC2 with your 2 patches.
> Like with the libretech-cc, sdr104 at 200Mhz works "mostly", but, with some
> sdcards, it does not - please see below. The same sdcards appear to be working
> fine on my laptop.
>
> This is something I have not been able to crack yet on the libretech-cc.
>
> I'd suggest dropping sdr104 and keeping the max frequency at 100Mhz until we can
> figure out the problem here.
>
> With this changed:
>
> Tested-by: Jerome Brunet <jbrunet@baylibre.com>
>
> dd if=/dev/mmcblk1 of=/dev/zero bs=4M
> [ 446.925817] mmc1: tuning execution failed: -5
> [ 446.956597] mmc1: tuning execution failed: -5
> [ 489.957810] print_req_error: I/O error, dev mmcblk1, sector 6654424
> [ 490.141975] print_req_error: I/O error, dev mmcblk1, sector 6656440
> [ 490.148304] print_req_error: I/O error, dev mmcblk1, sector 6656944
> [ 490.349650] print_req_error: I/O error, dev mmcblk1, sector 6658456
> [ 491.804382] print_req_error: I/O error, dev mmcblk1, sector 6747688
> [ 492.281246] print_req_error: I/O error, dev mmcblk1, sector 6784992
> [ 492.419034] print_req_error: I/O error, dev mmcblk1, sector 6785496
> [ 492.865878] print_req_error: I/O error, dev mmcblk1, sector 6791800
> [ 493.023809] print_req_error: I/O error, dev mmcblk1, sector 6792192
> [ 493.024435] Buffer I/O error on dev mmcblk1, logical block 849024, async page
> read
> [ 493.217751] print_req_error: I/O error, dev mmcblk1, sector 6792808
> [ 494.891779] mmc1: tuning execution failed: -5
> [ 495.374186] print_req_error: 3 callbacks suppressed
> [ 495.374193] print_req_error: I/O error, dev mmcblk1, sector 6854576
> [ 495.767498] print_req_error: I/O error, dev mmcblk1, sector 6860000
> [ 496.013104] print_req_error: I/O error, dev mmcblk1, sector 6863024
> [ 496.223042] print_req_error: I/O error, dev mmcblk1, sector 6864032
> [ 496.227003] print_req_error: I/O error, dev mmcblk1, sector 6864536
> [ 496.375175] print_req_error: I/O error, dev mmcblk1, sector 6864176
> [ 496.375806] Buffer I/O error on dev mmcblk1, logical block 858022, async page
> read
> [ 496.521229] print_req_error: I/O error, dev mmcblk1, sector 6864184
> [ 496.521852] Buffer I/O error on dev mmcblk1, logical block 858023, async page
> read
> [ 503.596978] print_req_error: I/O error, dev mmcblk1, sector 6983312
> [ 503.597606] Buffer I/O error on dev mmcblk1, logical block 872914, async page
> read
> [ 505.280621] print_req_error: I/O error, dev mmcblk1, sector 7004536
> [ 505.281249] Buffer I/O error on dev mmcblk1, logical block 875567, async page
> read
> [ 507.372560] print_req_error: I/O error, dev mmcblk1, sector 7048696
> [ 507.373192] Buffer I/O error on dev mmcblk1, logical block 881087, async page
> read
> [ 511.355248] print_req_error: I/O error, dev mmcblk1, sector 7131352
> [ 511.355883] Buffer I/O error on dev mmcblk1, logical block 891419, async page
> read
> [ 511.369076] print_req_error: I/O error, dev mmcblk1, sector 7131352
> [ 511.369694] Buffer I/O error on dev mmcblk1, logical block 891419, async page
> read
> dd: error reading '/dev/mmcblk1': Input/output error
> 868+7 records in
> 868+7 records out
> 3651252224 bytes (3.7 GB, 3.4 GiB) copied, 66.7736 s, 54.7 MB/s
Thank for your testing, I will also do some more testing on all the
sdcard and share you the result..
Mean while Sandisk Ultra microSDHC UHS-I card @A1 32GB shows.
On my Odroid C2:
[ 1.165784] meson-gx-mmc d0074000.mmc: allocated mmc-pwrseq
[ 1.403756] meson-gx-mmc d0072000.mmc: Got CD GPIO
[ 1.456160] Waiting for root device /dev/mmcblk1p2...
[ 1.608180] mmc1: new ultra high speed SDR104 SDHC card at address aaaa
[ 1.610002] mmcblk1: mmc1:aaaa JULIE 29.7 GiB
[ 1.617811] mmcblk1: p1 p2
Also I did not encounter and read/write failure on the sdcard but I
will re-test them.
root at odroid64:~# dd if=/dev/mmcblk1 of=/dev/zero bs=4M
7609+1 records in
7609+1 records out
31914983424 bytes (32 GB, 30 GiB) copied, 368.637 s, 86.6 MB/s
root at odroid64:~#
Best Regards
-Anand
^ permalink raw reply
* [PATCH V3] ARM: dts: da850-evm: Enable LCD and Backlight
From: Laurent Pinchart @ 2018-05-15 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xKgop-SMZpQm4jca3NB0rrc_CCcMG8JL6mayLx4u+zW9w@mail.gmail.com>
Hi Adam,
On Monday, 14 May 2018 21:04:07 EEST Adam Ford wrote:
> On Mon, May 14, 2018 at 7:35 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> > On Monday 14 May 2018 04:22 PM, Adam Ford wrote:
> >> On Mon, May 14, 2018 at 12:29 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> >>> Hi Adam,
>
> Added Tomi, Laurent, and Jyri for feedback.
>
> >>> On Monday 14 May 2018 04:50 AM, Adam Ford wrote:
> >>>> When using the board files the LCD works, but not with the DT.
> >>>> This adds enables the original da850-evm to work with the same
> >>>> LCD in device tree mode.
> >>>>
> >>>> The EVM has a gpio for the regulator and a gpio enable. The LCD and
> >>>> the vpif display pins are mutually exclusive, so if using the LCD,
> >>>> do not load the vpif driver.
> >>>
> >>> Its not sufficient just note this in patch description.
> >>>
> >>> a) Disable (status = "disabled") the VPIF node which clashes for pins
> >>> with LCD.
> >>> b) Add a comment on top of the status = "disabled" giving information on
> >>> how user can enable it (disable lcdc node and then change to status =
> >>> "okay").
> >>>
> >>>> Signed-off-by: Adam Ford <aford173@gmail.com>
> >>>> ---
> >>>> V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be
> >>>> more explict to backlight which better matches the schematic.
> >>>> Updated the description to explain that it cannot be used at the
> >>>> same time as the vpif driver.
> >>>>
> >>>> V2: Add regulator and GPIO enable pins. Remove PWM backlight and
> >>>> replace with GPIO
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/da850-evm.dts
> >>>> b/arch/arm/boot/dts/da850-evm.dts index 2e817da37fdb..3f1c8be07efe
> >>>> 100644
> >>>> --- a/arch/arm/boot/dts/da850-evm.dts
> >>>> +++ b/arch/arm/boot/dts/da850-evm.dts
> >>>> @@ -27,6 +27,50 @@
> >>>> spi0 = &spi1;
> >>>> };
> >>>>
> >>>> + backlight {
> >>>> + compatible = "gpio-backlight";
> >>>> + enable-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; /* GP0[7] */
> >>>
> >>> The gpio-backlight binding does not describe a property called
> >>> enable-gpios. It should just be gpios.
> >>
> >> I will fix that.
> >>
> >>> a) Are you using gpio-backlight because you are not able to get the PWM
> >>> to work?
> >>
> >> Yes, You told me not to worry about doing a PWM backlight because the
> >> legacy board does not PWM either.
> >
> > Yeah, I meant not to add backlight control till the time we are able to
> > get it working using PWM. Is this needed for the basic LCD functionality
> > to work? I would like to avoid the churn of adding it using GPIO now and
> > changing to PWM later, if possible.
> >
> >>> b) What is GP0[7] connected to in the schematic you have? In the
> >>> schematic I have I see LCD_PWM0 is connected to
> >>> SPI1_SCS[0]/EPWM1B/GP2[14]/TM64P3_IN12.
> >>
> >> I have schematic 1016572 dated Wednesday, August 18, 2010. According
> >> to it, AXR15 / EPWMN0_TZ[0] / ECAP2_APWM2 / GPIO0[7] connects to U25,
> >> Pin 46 to generate M_LCD_PWM0. You might have one of the early,
> >> pre-release versions.
> >
> > Ah, okay. In your schematic, is GP2[14] connected to anything?
> >
> >>> c) The /* GP0[7] */ comment is not really useful on its own as it can be
> >>> computed. What I wanted to see is the schematic symbol like "LCD_PWM0".
> >>> Same for other places like this below.
> >>
> >> I can do that.
> >>
> >>>> @@ -35,6 +79,16 @@
> >>>> regulator-boot-on;
> >>>> };
> >>>>
> >>>> + backlight_reg: backlight-regulator {
> >>>> + compatible = "regulator-fixed";
> >>>> + regulator-name = "lcd_backlight_pwr";
> >>>> + regulator-min-microvolt = <3300000>;
> >>>> + regulator-max-microvolt = <3300000>;
> >>>> + gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* GP2[15] */
> >>>> + regulator-always-on;
> >>>
> >>> Why should this regulator never be disabled?
> >>
> >> The gpio-backlight does not have a way that I can see to associate the
> >> regulator to it. I read through the bindings, but I didn't see an
> >> option to associate a regulator it. I use this regulator to drive
> >> lcd_backlight_pwr and the backlight driver to write lcd_pwm0. Without
> >> this option, the system disables lcd_backlight_pwr and the screen is
> >> blank
> >
> > It sounds like this is a hack to enable backlight on this board. I think
> > either the backlight driver needs to gain functionality to enable the
> > GPIO. Or backlight could be treated as part of the panel and enabled
> > using enable-gpios property in the panel. TBH, I will be okay either
> > way. Can you check with Jyri, Tomi and rest of the DRM folks on what
> > should be right way of dealing with this?
>
> Per your request I added them into this thread. I added Tomi, Jyri,
> and Laurent to this as Laurent's name is associated with the gpio
> backlight driver.
>
> I am not sure why you think it's a hack. I pulled up the schematic
> for the LCD to see what it's doing, and the lcd_backlight_pwr pin
> controls the power-on sequence of the back-light controller. Without
> this, there is no power, so it seems to me that the 'regulator-fixed'
> device is the correct way to do it.
It's a hack because keeping the backlight power on when the display is off
will consume power unnecessarily. The backlight power should be turned off in
that case.
> The separate pin associated to the gpio is used to tell the backlight
> IC to actually turn on/off the back-light. Ideally it seems like it
> would nice to have the gpio-backlight driver be able to specify the
> regulator, so when the backlight is in use, it would power the
> regulator, but until that's available, the it seems like
> 'regulator-always-on' is the way to make it stay on.
>
> Laurent, Jyri, Tomi, do you have any thoughts on this matter?
This has been attempted 6 years ago, and got rejected. See https://lwn.net/
Articles/525422/.
The problem is that the number of power supplies, the order in which they need
to be sequenced, and the related timings (as in delays required between
turning power supplies on/off) is highly hardware-specific. We can't hardcode
a specific sequence and specific timings in the gpio-backlight (or pwm-
backlight) driver, and specifying the sequence in DT was considered to be
over-engineered.
You thus have two options, either creating a custom backlight driver that will
handle the power supplies specific to your backlight controller, or
integrating backlight power supply control in your panel driver. If the power
supplies also power the panel and not just the backlight, or if their
sequencing depends in any way on the panel model in which the backlight
controller is integrated, I'd go for the latter, otherwise you can pick any of
the two methods.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH V3] ARM: dts: da850-evm: Enable LCD and Backlight
From: Sekhar Nori @ 2018-05-15 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xKgop-SMZpQm4jca3NB0rrc_CCcMG8JL6mayLx4u+zW9w@mail.gmail.com>
On Monday 14 May 2018 11:34 PM, Adam Ford wrote:
> On Mon, May 14, 2018 at 7:35 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Monday 14 May 2018 04:22 PM, Adam Ford wrote:
>>> On Mon, May 14, 2018 at 12:29 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> Hi Adam,
>
> Added Tomi, Laurent, and Jyri for feedback.
>
>>>>
>>>> On Monday 14 May 2018 04:50 AM, Adam Ford wrote:
>>>>> When using the board files the LCD works, but not with the DT.
>>>>> This adds enables the original da850-evm to work with the same
>>>>> LCD in device tree mode.
>>>>>
>>>>> The EVM has a gpio for the regulator and a gpio enable. The LCD and
>>>>> the vpif display pins are mutually exclusive, so if using the LCD,
>>>>> do not load the vpif driver.
>>>>
>>>> Its not sufficient just note this in patch description.
>>>>
>>>> a) Disable (status = "disabled") the VPIF node which clashes for pins
>>>> with LCD.
>>>> b) Add a comment on top of the status = "disabled" giving information on
>>>> how user can enable it (disable lcdc node and then change to status =
>>>> "okay").
>>>>
>>>>>
>>>>> Signed-off-by: Adam Ford <aford173@gmail.com>
>>>>> ---
>>>>> V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be more explict to
>>>>> backlight which better matches the schematic. Updated the description to explain
>>>>> that it cannot be used at the same time as the vpif driver.
>>>>>
>>>>> V2: Add regulator and GPIO enable pins. Remove PWM backlight and replace with GPIO
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>>>>> index 2e817da37fdb..3f1c8be07efe 100644
>>>>> --- a/arch/arm/boot/dts/da850-evm.dts
>>>>> +++ b/arch/arm/boot/dts/da850-evm.dts
>>>>> @@ -27,6 +27,50 @@
>>>>> spi0 = &spi1;
>>>>> };
>>>>>
>>>>> + backlight {
>>>>> + compatible = "gpio-backlight";
>>>>> + enable-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; /* GP0[7] */
>>>>
>>>> The gpio-backlight binding does not describe a property called
>>>> enable-gpios. It should just be gpios.
>>>
>>> I will fix that.
>>>
>>>>
>>>> a) Are you using gpio-backlight because you are not able to get the PWM
>>>> to work?
>>>>
>>> Yes, You told me not to worry about doing a PWM backlight because the
>>> legacy board does not PWM either.
>>
>> Yeah, I meant not to add backlight control till the time we are able to
>> get it working using PWM. Is this needed for the basic LCD functionality
>> to work? I would like to avoid the churn of adding it using GPIO now and
>> changing to PWM later, if possible.
>>
>>>
>>>> b) What is GP0[7] connected to in the schematic you have? In the
>>>> schematic I have I see LCD_PWM0 is connected to
>>>> SPI1_SCS[0]/EPWM1B/GP2[14]/TM64P3_IN12.
>>>
>>> I have schematic 1016572 dated Wednesday, August 18, 2010. According
>>> to it, AXR15 / EPWMN0_TZ[0] / ECAP2_APWM2 / GPIO0[7] connects to U25,
>>> Pin 46 to generate M_LCD_PWM0. You might have one of the early,
>>> pre-release versions.
>>
>> Ah, okay. In your schematic, is GP2[14] connected to anything?
>>
>>>
>>>>
>>>> c) The /* GP0[7] */ comment is not really useful on its own as it can be
>>>> computed. What I wanted to see is the schematic symbol like "LCD_PWM0".
>>>> Same for other places like this below.
>>>
>>> I can do that.
>>>>
>>>>> @@ -35,6 +79,16 @@
>>>>> regulator-boot-on;
>>>>> };
>>>>>
>>>>> + backlight_reg: backlight-regulator {
>>>>> + compatible = "regulator-fixed";
>>>>> + regulator-name = "lcd_backlight_pwr";
>>>>> + regulator-min-microvolt = <3300000>;
>>>>> + regulator-max-microvolt = <3300000>;
>>>>> + gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* GP2[15] */
>>>>> + regulator-always-on;
>>>>
>>>> Why should this regulator never be disabled?
>>>
>>> The gpio-backlight does not have a way that I can see to associate the
>>> regulator to it. I read through the bindings, but I didn't see an
>>> option to associate a regulator it. I use this regulator to drive
>>> lcd_backlight_pwr and the backlight driver to write lcd_pwm0. Without
>>> this option, the system disables lcd_backlight_pwr and the screen is
>>> blank
>>
>> It sounds like this is a hack to enable backlight on this board. I think
>> either the backlight driver needs to gain functionality to enable the
>> GPIO. Or backlight could be treated as part of the panel and enabled
>> using enable-gpios property in the panel. TBH, I will be okay either
>> way. Can you check with Jyri, Tomi and rest of the DRM folks on what
>> should be right way of dealing with this?
>
> Per your request I added them into this thread. I added Tomi, Jyri,
> and Laurent to this as Laurent's name is associated with the gpio
> backlight driver.
Okay. The reason I did not loop them in myself is because I thought a
fresh thread with background will be better. But okay.
> I am not sure why you think it's a hack. I pulled up the schematic
> for the LCD to see what it's doing, and the lcd_backlight_pwr pin
> controls the power-on sequence of the back-light controller. Without
> this, there is no power, so it seems to me that the 'regulator-fixed'
> device is the correct way to do it.
Not questioning modeling the GPIO as a regulator.
>
> The separate pin associated to the gpio is used to tell the backlight
> IC to actually turn on/off the back-light. Ideally it seems like it
> would nice to have the gpio-backlight driver be able to specify the
> regulator, so when the backlight is in use, it would power the
> regulator, but until that's available, the it seems like
> 'regulator-always-on' is the way to make it stay on.
We need to add support for this in backlight driver. Using
regulator-always-on to paper over this lack of support in backlight
driver is what I am calling a hack. 'regulator-always-on' means the
regulator cannot be turned off. Thats certainly not the case as you have
pointed out.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v9 06/11] arm64: kexec_file: allow for loading Image-format kernel
From: AKASHI Takahiro @ 2018-05-15 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6f0df3a8-a691-80f1-85de-3e0ead852f12@arm.com>
James,
On Fri, May 11, 2018 at 06:07:06PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 07/05/18 08:21, AKASHI Takahiro wrote:
> > On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote:
> >> On 25/04/18 07:26, AKASHI Takahiro wrote:
> >>> This patch provides kexec_file_ops for "Image"-format kernel. In this
> >>> implementation, a binary is always loaded with a fixed offset identified
> >>> in text_offset field of its header.
>
> >>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> >>> index e4de1223715f..3cba4161818a 100644
> >>> --- a/arch/arm64/include/asm/kexec.h
> >>> +++ b/arch/arm64/include/asm/kexec.h
> >>> @@ -102,6 +102,56 @@ struct kimage_arch {
> >>> void *dtb_buf;
> >>> };
> >>>
> >>> +/**
> >>> + * struct arm64_image_header - arm64 kernel image header
> >>> + *
> >>> + * @pe_sig: Optional PE format 'MZ' signature
To be precise, this is NOT a PE signature but MS-DOS header's magic.
(There is another "PE" signature in PE COFF file header pointed to by
'pe_header'.)
I will correct its name.
> >>> + * @branch_code: Instruction to branch to stext
> >>> + * @text_offset: Image load offset, little endian
> >>> + * @image_size: Effective image size, little endian
> >>> + * @flags:
> >>> + * Bit 0: Kernel endianness. 0=little endian, 1=big endian
> >>
> >> Page size? What about 'phys_base'?, (whatever that is...)
> >> Probably best to refer to Documentation/arm64/booting.txt here, its the
> >> authoritative source of what these fields mean.
> >
> > While we don't care other bit fields for now, I will add the reference
> > to the Documentation file.
>
> Thanks, I don't want to create a second, incomplete set of documentation!
I will leave a minimum of description of parameters here.
>
>
> >>> + u64 reserved[3];
> >>> + u8 magic[4];
> >>> + u32 pe_header;
> >>> +};
> >>
> >> I'm surprised we don't have a definition for this already, I guess its always
> >> done in asm. We have kernel/image.h that holds some of this stuff, if we are
> >> going to validate the flags, is it worth adding the code there, (and moving it
> >> to include/asm)?
> >
> > A comment at the beginning of this file says,
> > #ifndef LINKER_SCRIPT
> > #error This file should only be included in vmlinux.lds.S
> > #endif
> > Let me think about.
>
> Ah, I missed that.
>
> Having two definitions of something makes me nervous that they can become
> different... looks like that header belongs to the linker, and shouldn't be used
> here then.
OK.
>
> >> I guess you skip the MZ prefix as its not present for !EFI?
Correct, but MZ checking in probe function is just an informative message.
> >
> > CONFIG_KEXEC_IMAGE_VERIFY_SIG depends on the fact that the file
> > format is PE (that is, EFI is enabled).
>
> So if the signature checking is enabled, its already been checked.
The signature, either MZ or PE, in a file will be actually checked
in verify_pefile_signature().
>
> >> Could we check branch_code is non-zero, and text-offset points within image-size?
> >
> > We could do it, but I don't think this check is very useful.
> >
> >>
> >> We could check that this platform supports the page-size/endian config that this
> >> Image was built with... We get a message from the EFI stub if the page-size
> >> can't be supported, it would be nice to do the same here (as we can).
> >
> > There is no restriction on page-size or endianness for kexec.
>
> No, but it won't boot if the hardware doesn't support it. The kernel will spin
> at a magic address that is, difficult, to debug without JTAG. The bug report
> will be "it didn't boot".
OK.
Added sanity checks for cpu features, endianness as well as page size.
>
> > What will be the purpose of this check?
>
> These values are in the header so that the bootloader can check them, then print
> a meaningful error. Here, kexec_file_load() is playing the part of the bootloader.
>
> I'm assuming kexec_file_load() can only be used to kexec linux... unlike regular
> kexec. Is this where I'm going wrong?
>
>
> >>> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> >>> new file mode 100644
> >>> index 000000000000..4dd524ad6611
> >>> --- /dev/null
> >>> +++ b/arch/arm64/kernel/kexec_image.c
> >>> @@ -0,0 +1,79 @@
> >>
> >>> +static void *image_load(struct kimage *image,
> >>> + char *kernel, unsigned long kernel_len,
> >>> + char *initrd, unsigned long initrd_len,
> >>> + char *cmdline, unsigned long cmdline_len)
> >>> +{
> >>> + struct kexec_buf kbuf;
> >>> + struct arm64_image_header *h = (struct arm64_image_header *)kernel;
> >>> + unsigned long text_offset;
> >>> + int ret;
> >>> +
> >>> + /* Load the kernel */
> >>> + kbuf.image = image;
> >>> + kbuf.buf_min = 0;
> >>> + kbuf.buf_max = ULONG_MAX;
> >>> + kbuf.top_down = false;
> >>> +
> >>> + kbuf.buffer = kernel;
> >>> + kbuf.bufsz = kernel_len;
> >>> + kbuf.memsz = le64_to_cpu(h->image_size);
> >>> + text_offset = le64_to_cpu(h->text_offset);
> >>> + kbuf.buf_align = SZ_2M;
> >>
> >>> + /* Adjust kernel segment with TEXT_OFFSET */
> >>> + kbuf.memsz += text_offset;
> >>> +
> >>> + ret = kexec_add_buffer(&kbuf);
> >>> + if (ret)
> >>> + goto out;
> >>> +
> >>> + image->arch.kern_segment = image->nr_segments - 1;
> >>
> >> You only seem to use kern_segment here, and in load_other_segments() called
> >> below. Could it not be a local variable passed in? Instead of arch-specific data
> >> we keep forever?
> >
> > No, kern_segment is also used in load_other_segments() in machine_kexec_file.c.
> > To optimize memory hole allocation logic in locate_mem_hole_callback(),
> > we need to know the exact range of kernel image (start and end).
>
> That's the second user. My badly-made point is one calls the other, but passes
> the data via some until-kexec lifetime struct. (its not important, just an
> indicator this worked differently in the past and hasn't been cleaned up).
> I meant something like [0].
OK, but instead of adding kern_seg, I want to change the interface to:
| extern int load_other_segments(struct kimage *image,
| unsigned long kernel_load_addr, unsigned long kernel_size,
| char *initrd, unsigned long initrd_len,
| char *cmdline, unsigned long cmdline_len);
This way, we will in future be able to address an issue I mentioned in
my previous e-mail. (If we support vmlinux, the kernel occupies two segments
for text and data, respectively.)
Thanks,
-Takahiro AKASHI
>
> Thanks,
>
> James
>
>
> [0] a diff is worth a thousand words:
> --------------------%<--------------------
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_
> kexec_file.c
> index 762f9102899c..c50ce844f09e 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -325,11 +325,10 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
> return ret;
> }
>
> -int load_other_segments(struct kimage *image,
> +int load_other_segments(struct kimage *image, struct kexec_segment *kern_seg,
> char *initrd, unsigned long initrd_len,
> char *cmdline, unsigned long cmdline_len)
> {
> - struct kexec_segment *kern_seg;
> struct kexec_buf kbuf;
> void *hdrs_addr;
> unsigned long hdrs_sz;
> @@ -368,7 +367,6 @@ int load_other_segments(struct kimage *image,
> image->arch.elf_load_addr, hdrs_sz, hdrs_sz);
> }
>
> - kern_seg = &image->segment[image->arch.kern_segment];
> kbuf.image = image;
> /* not allocate anything below the kernel */
> kbuf.buf_min = kern_seg->mem + kern_seg->memsz;
> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> index 891f2484969d..085cb69293ca 100644
> --- a/arch/arm64/include/asm/kexec.h
> +++ b/arch/arm64/include/asm/kexec.h
> @@ -173,8 +172,10 @@ static inline int arm64_header_check_pe_sig(const struct ar
> m64_image_header *h)
> extern const struct kexec_file_ops kexec_image_ops;
>
> struct kimage;
> +struct kexec_segment;
>
> extern int load_other_segments(struct kimage *image,
> + struct kexec_segment *kern_seg,
> char *initrd, unsigned long initrd_len,
> char *cmdline, unsigned long cmdline_len);
> #endif
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 7c11beefe65f..0e032d30a79c 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -37,6 +37,7 @@ static void *image_load(struct kimage *image,
> char *cmdline, unsigned long cmdline_len)
> {
> struct kexec_buf kbuf;
> + struct kexec_segment *kern_seg;
> struct arm64_image_header *h = (struct arm64_image_header *)kernel;
> unsigned long text_offset;
> int ret;
> @@ -65,17 +66,17 @@ static void *image_load(struct kimage *image,
> if (ret)
> goto out;
>
> - image->arch.kern_segment = image->nr_segments - 1;
> - image->segment[image->arch.kern_segment].mem += text_offset;
> - image->segment[image->arch.kern_segment].memsz -= text_offset;
> - image->start = image->segment[image->arch.kern_segment].mem;
> + kern_seg = &image->segment[image->nr_segments - 1];
> + kern_seg->mem += text_offset;
> + kern_seg->memsz -= text_offset;
> + image->start = kern_seg->mem;
>
> pr_debug("Loaded kernel at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> - image->segment[image->arch.kern_segment].mem,
> + kern_seg->mem,
> kbuf.bufsz, kbuf.memsz);
>
> /* Load additional data */
> - ret = load_other_segments(image, initrd, initrd_len,
> + ret = load_other_segments(image, kern_seg, initrd, initrd_len,
> cmdline, cmdline_len);
>
> out:
> --------------------%<--------------------
^ permalink raw reply
* [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory
From: AKASHI Takahiro @ 2018-05-15 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ece8d3cc-127f-6855-52fb-24e4a1d4e823@arm.com>
James,
On Fri, May 11, 2018 at 06:03:49PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 07/05/18 06:22, AKASHI Takahiro wrote:
> > On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
> >> On 25/04/18 07:26, AKASHI Takahiro wrote:
> >>> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> >>> index f76ea92dff91..f7dbba00be10 100644
> >>> --- a/arch/arm64/kernel/machine_kexec.c
> >>> +++ b/arch/arm64/kernel/machine_kexec.c
> >>> @@ -205,10 +205,17 @@ void machine_kexec(struct kimage *kimage)
>
> >>> cpu_soft_restart(kimage != kexec_crash_image,
> >>> - reboot_code_buffer_phys, kimage->head, kimage->start, 0);
> >>> + reboot_code_buffer_phys, kimage->head, kimage->start,
> >>> +#ifdef CONFIG_KEXEC_FILE
> >>> + kimage->purgatory_info.purgatory_buf ?
> >>> + 0 : kimage->arch.dtb_mem);
> >>> +#else
> >>> + 0);
> >>> +#endif
>
>
> >> purgatory_buf seems to only be set in kexec_purgatory_setup_kbuf(), called from
> >> kexec_load_purgatory(), which we don't use. How does this get a value?
> >>
> >> Would it be better to always use kimage->arch.dtb_mem, and ensure that is 0 for
> >> regular kexec (as we can't know where the dtb is)? (image_arg may then be a
> >> better name).
> >
> > The problem is arch.dtb_mem is currently defined only if CONFIG_KEXEC_FILE.
>
> I thought it was ARCH_HAS_KIMAGE_ARCH, which we can define all the time if
> that's what we want.
>
>
> > So I would like to
> > - merge this patch with patch#8
> > - change the condition
> > #ifdef CONFIG_KEXEC_FILE
> > kimage->file_mode ? kimage->arch.dtb_mem : 0);
> > #else
> > 0);
> > #endif
>
> If we can avoid even this #ifdef by always having kimage->arch, I'd prefer that.
> If we do that 'dtb_mem' would need some thing that indicates its for kexec_file,
> as kexec has a DTB too, we just don't know where it is...
OK, but I want to have a minimum of kexec.arch always exist.
How about this?
| #define ARCH_HAS_KIMAGE_ARCH
|
| struct kimage_arch {
| phys_addr_t dtb_mem;
| #ifdef CONFIG_KEXEC_FILE
| void *dtb_buf;
| /* Core ELF header buffer */
| void *elf_headers;
| unsigned long elf_headers_sz;
| unsigned long elf_load_addr;
| #endif
| void machine_kexec(struct kimage *kimage)
| {
| ...
| cpu_soft_restart(kimage != kexec_crash_image,
| reboot_code_buffer_phys, kimage->head, kimage->start,
| kimage->arch.dtb_mem);
Thanks
-Takahiro AKASHI
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: sdm845: Sort nodes in the reserved mem by address
From: Douglas Anderson @ 2018-05-15 4:43 UTC (permalink / raw)
To: linux-arm-kernel
Let's keep the reserved-memory node tidy and neat and keep it sorted
by address. This should have no functional change.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- Oops! v1 accidentally changed the node name. Fixed.
arch/arm64/boot/dts/qcom/sdm845.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 7c85e7c596db..73f71061fef8 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -31,6 +31,12 @@
no-map;
};
+ memory at 85fe0000 {
+ compatible = "qcom,cmd-db";
+ reg = <0x0 0x85fe0000 0x0 0x20000>;
+ no-map;
+ };
+
smem_mem: memory at 86000000 {
reg = <0x0 0x86000000 0x0 0x200000>;
no-map;
@@ -40,12 +46,6 @@
reg = <0 0x86200000 0 0x2d00000>;
no-map;
};
-
- memory at 85fe0000 {
- compatible = "qcom,cmd-db";
- reg = <0x0 0x85fe0000 0x0 0x20000>;
- no-map;
- };
};
cpus {
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
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