* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Greg Kroah-Hartman @ 2018-05-24 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-2-robh@kernel.org>
On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:
> Deferred probe will currently wait forever on dependent devices to probe,
> but sometimes a driver will never exist. It's also not always critical for
> a driver to exist. Platforms can rely on default configuration from the
> bootloader or reset defaults for things such as pinctrl and power domains.
> This is often the case with initial platform support until various drivers
> get enabled. There's at least 2 scenarios where deferred probe can render
> a platform broken. Both involve using a DT which has more devices and
> dependencies than the kernel supports. The 1st case is a driver may be
> disabled in the kernel config. The 2nd case is the kernel version may
> simply not have the dependent driver. This can happen if using a newer DT
> (provided by firmware perhaps) with a stable kernel version.
>
> Subsystems or drivers may opt-in to this behavior by calling
> driver_deferred_probe_check_init_done() instead of just returning
> -EPROBE_DEFER. They may use additional information from DT or kernel's
> config to decide whether to continue to defer probe or not.
>
> Cc: Alexander Graf <agraf@suse.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/base/dd.c | 17 +++++++++++++++++
> include/linux/device.h | 2 ++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index c9f54089429b..d6034718da6f 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -226,6 +226,16 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
> +{
> + if (optional && initcalls_done) {
Wait, what's the "optional" mess here?
The caller knows this value, so why do you need to even pass it in here?
And bool values that are not obvious are horrid. I had to go look this
up when reading the later patches that just passed "true" in this
variable as I had no idea what that meant.
So as-is, no, this isn't ok, sorry.
And at the least, this needs some kerneldoc to explain it :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Greg Kroah-Hartman @ 2018-05-24 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-2-robh@kernel.org>
On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:
> Deferred probe will currently wait forever on dependent devices to probe,
> but sometimes a driver will never exist. It's also not always critical for
> a driver to exist. Platforms can rely on default configuration from the
> bootloader or reset defaults for things such as pinctrl and power domains.
> This is often the case with initial platform support until various drivers
> get enabled. There's at least 2 scenarios where deferred probe can render
> a platform broken. Both involve using a DT which has more devices and
> dependencies than the kernel supports. The 1st case is a driver may be
> disabled in the kernel config. The 2nd case is the kernel version may
> simply not have the dependent driver. This can happen if using a newer DT
> (provided by firmware perhaps) with a stable kernel version.
>
> Subsystems or drivers may opt-in to this behavior by calling
> driver_deferred_probe_check_init_done() instead of just returning
> -EPROBE_DEFER. They may use additional information from DT or kernel's
> config to decide whether to continue to defer probe or not.
>
> Cc: Alexander Graf <agraf@suse.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/base/dd.c | 17 +++++++++++++++++
> include/linux/device.h | 2 ++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index c9f54089429b..d6034718da6f 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -226,6 +226,16 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
> +{
> + if (optional && initcalls_done) {
> + dev_WARN(dev, "ignoring dependency for device, assuming no driver");
You really only need dev_warn(), here, right?
thanks,
greg k-h
^ permalink raw reply
* [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
From: Bjorn Helgaas @ 2018-05-24 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61f70fd6-52fd-da07-ce73-303f95132131@codeaurora.org>
On Wed, May 23, 2018 at 06:57:18PM -0400, Sinan Kaya wrote:
> On 5/23/2018 5:32 PM, Bjorn Helgaas wrote:
> >
> > The crash seems to indicate that the hpsa device attempted a DMA after
> > we cleared the Root Port's PCI_COMMAND_MASTER, which means
> > hpsa_shutdown() didn't stop DMA from the device (it looks like *most*
> > shutdown methods don't disable device DMA, so it's in good company).
>
> All drivers are expected to shutdown DMA and interrupts in their shutdown()
> routines. They can skip removing threads, data structures etc. but DMA and
> interrupt disabling are required. This is the difference between shutdown()
> and remove() callbacks.
>
> If you see that this is not being done in HPSA, then that is where the
> bugfix should be.
>
> Counter argument is that if shutdown() is not implemented, at least remove()
> should be called. Expecting all drivers to implement shutdown() callbacks
> is just bad by design in my opinion.
>
> Code should have fallen back to remove() if shutdown() doesn't exist.
> I can propose a patch for this but this is yet another story to chase.
That sounds like a reasonable idea, and it is definitely another can
of worms. I looked briefly at some of the .shutdown() cases:
- device_shutdown() doesn't fall back to remove().
- It looks like most bus_types don't implement .shutdown() at all (I
didn't look at them all).
- Of the bus_types that do implement .shutdown(), most do not fall
back to .remove(). ps3_system_bus_type() is an example of one
that *does* fall back to a driver's .remove() if there is no
.shutdown().
Implement shutdown (no fallback unless indicated):
ecard_bus_type
gio_bus_type
ps3_system_bus_type # does fallback to remove
ibmebus_bus_type
isa_bus_type
platform_bus_type # not direct implementation
fmc_bus_type # fmc_shutdown() looks spurious
mipi_dsi_bus_type
hv_bus
> >> This has been found to cause crashes on HP DL360 Gen9 machines during
> >> reboot. Besides, kexec is already clearing the bus master bit in
> >> pci_device_shutdown() after all PCI drivers are removed.
> >
> > The original path was:
> >
> > pci_device_shutdown(hpsa)
> > drv->shutdown
> > hpsa_shutdown # hpsa_pci_driver.shutdown
> > ...
> > pci_device_shutdown(RP) # root port
> > drv->shutdown
> > pcie_portdrv_remove # pcie_portdriver.shutdown
> > pcie_port_device_remove
> > pci_disable_device
> > do_pci_disable_device
> > # clear RP PCI_COMMAND_MASTER
> > if (kexec)
> > pci_clear_master(RP)
> > # clear RP PCI_COMMAND_MASTER
> >
> > If I understand correctly, the new path after this patch is:
> >
> > pci_device_shutdown(hpsa)
> > drv->shutdown
> > hpsa_shutdown # hpsa_pci_driver.shutdown
> > ...
> > pci_device_shutdown(RP) # root port
> > drv->shutdown
> > pcie_portdrv_shutdown # pcie_portdriver.shutdown
> > __pcie_portdrv_remove(RP, false)
> > pcie_port_device_remove(RP, false)
> > # do NOT clear RP PCI_COMMAND_MASTER
>
> yup
>
> > if (kexec)
> > pci_clear_master(RP)
> > # clear RP PCI_COMMAND_MASTER
> >
> > I guess this patch avoids the panic during reboot because we're not in
> > the kexec path, so we never clear PCI_COMMAND_MASTER for the Root
> > Port, so the hpsa device can DMA happily until the lights go out.
> >
> > But DMA continuing for some random amount of time before the reboot or
> > shutdown happens makes me a little queasy. That doesn't sound safe.
> > The more I think about this, the more confused I get. What am I
> > missing?
>
> see above.
>
> >
> >> Just remove the extra clear in shutdown path by seperating the remove and
> >> shutdown APIs in the PORTDRV.
> >>
> >> static pci_ers_result_t pcie_portdrv_error_detected(struct pci_dev *dev,
> >> @@ -218,7 +228,7 @@ static struct pci_driver pcie_portdriver = {
> >>
> >> .probe = pcie_portdrv_probe,
> >> .remove = pcie_portdrv_remove,
> >> - .shutdown = pcie_portdrv_remove,
> >> + .shutdown = pcie_portdrv_shutdown,
> >
> > What are the circumstances when we call .remove() vs .shutdown()?
> >
> > I guess the main (maybe only) way to call .remove() is to hot-remove
> > the port? And .shutdown() is basically used in the reboot and kexec
> > paths?
>
> Correct. shutdown() is only called during reboot/shutdown calls. If you echo
> 1 into the remove file, remove() gets called. Handy for hotplug use cases.
> It needs to be the exact opposite of the probe. It needs to clean up resources
> etc. and have the HW in a state where it can be reinitialized via probe again.
>
> >
> >> .err_handler = &pcie_portdrv_err_handler,
> >>
> >> --
> >> 2.7.4
> >>
> >
>
>
> --
> Sinan Kaya
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [GIT PULL 2/2] arm64: dts: exynos: Second round for v4.18
From: Krzysztof Kozlowski @ 2018-05-24 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524182016.5866-1-krzk@kernel.org>
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit 8dd6203f32f20cb83469eb859efded9e403b3e9f:
arm64: dts: exynos: Add mem-2-mem Scaler devices (2018-05-13 11:26:13 +0200)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.18-2
for you to fetch changes up to f0b5e8a21e6604980c35eeeba1ee3a124f45ad1f:
arm64: dts: exynos: Add more clocks to Exynos5433 Decon/DeconTV (2018-05-23 20:23:24 +0200)
----------------------------------------------------------------
Samsung DTS ARM64 changes for v4.18, part 2
1. Add clocks necessary for DECON hardware windows no 4 and 5 on
Exynos5433.
----------------------------------------------------------------
Marek Szyprowski (1):
arm64: dts: exynos: Add more clocks to Exynos5433 Decon/DeconTV
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
^ permalink raw reply
* [GIT PULL 1/2] ARM: dts: exynos: Second round for v4.18
From: Krzysztof Kozlowski @ 2018-05-24 18:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit 83cb529b2ef4f3446e60e75522d76fdaaea4724c:
ARM: dts: exynos: Update x and y properties for mms114 touchscreen (2018-05-13 15:15:49 +0200)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.18-2
for you to fetch changes up to 68605101460ea4c62a966b1ad3e8db90d8fbaa31:
ARM: dts: exynos: Add support for audio over HDMI for Odroid X/X2/U3 (2018-05-15 18:46:14 +0200)
----------------------------------------------------------------
Samsung DTS ARM changes for v4.18, part 2
1. Add support for audio over HDMI for Odroid X/X2/U3.
----------------------------------------------------------------
Sylwester Nawrocki (1):
ARM: dts: exynos: Add support for audio over HDMI for Odroid X/X2/U3
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 33 +++++++++++++++----------
arch/arm/boot/dts/exynos4412-odroidu3.dts | 6 ++---
arch/arm/boot/dts/exynos4412-odroidx.dts | 6 ++---
3 files changed, 26 insertions(+), 19 deletions(-)
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Mark Brown @ 2018-05-24 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-2-robh@kernel.org>
On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:
> Subsystems or drivers may opt-in to this behavior by calling
> driver_deferred_probe_check_init_done() instead of just returning
> -EPROBE_DEFER. They may use additional information from DT or kernel's
> config to decide whether to continue to defer probe or not.
Should userspace have some involvement in this decision? It knows if
it's got any intention of loading modules for example. Kernel config
checks might be good enough, though it's going to be a pain to work out
if the relevant driver is built as a module for example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180524/252c8b9e/attachment.sig>
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Mark Brown @ 2018-05-24 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175620.GB12093@piout.net>
On Thu, May 24, 2018 at 07:56:20PM +0200, Alexandre Belloni wrote:
> Back in 2014, I was suggesting using devm_gpio_request_one() in
> of_spi_register_master(). That would take care of setting the direction
> of the GPIO:
> https://www.spinics.net/lists/arm-kernel/msg351251.html
> I never took the time to create the patch and test though.
Right, this'd be ideal but unfortunately it does mean we'd have to
transition all the existing users that open code their requests which is
a pain. It'd be really nice if someone had the time/enthusiam to do it
though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180524/4bbd58ed/attachment.sig>
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Mark Brown @ 2018-05-24 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e6e71e2-f8ac-7889-0d81-8d8a4c15223d@microchip.com>
On Thu, May 24, 2018 at 07:04:11PM +0300, Radu Pirea wrote:
> if (ctlr->cs_gpios){
> spi->cs_gpio = ctlr->cs_gpios[spi->chip_select];
> if(gpio_is_valid(spi->cs_gpio))
> gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
>
> }
You're expected to request the GPIOs in your driver using one of the
modern request functions like gpio_request_one() (or ideally the GPIO
descriptor APIs now) which combine the direction setting and request
into a single operation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180524/afe4d42a/attachment.sig>
^ permalink raw reply
* [PATCH v2 02/13] ARM: pxa: add dma slave map
From: Robert Jarzmik @ 2018-05-24 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-3-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> In order to remove the specific knowledge of the dma mapping from PXA
> drivers, add a default slave map for pxa architectures.
>
> This is the first step, and once all drivers are converted,
> pxad_filter_fn() will be made static, and the DMA resources removed from
> device.c.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) },
> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) },
> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) },
Hi Arnd,
Actually after rereading this, I realised that I completely forgot your former
comment about having a NULL parameter for network devices (as there is no
requestor behind).
I will cook it up for v3 ... that will be a minor change in this patch (hence
I'll keep any Ack), but for patches 0006 and 0007, things will change, and
another patch for Vinod will appear.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Alexandre Belloni @ 2018-05-24 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e6e71e2-f8ac-7889-0d81-8d8a4c15223d@microchip.com>
Hi,
On 24/05/2018 19:04:11+0300, Radu Pirea wrote:
>
>
> On 05/17/2018 07:54 AM, Mark Brown wrote:
> > On Tue, May 15, 2018 at 12:22:24PM +0300, Radu Pirea wrote:
> > > On Mon, 2018-05-14 at 20:38 +0300, Andy Shevchenko wrote:
> >
> > > > So, what is not going as expected in "SPI core takes care of CSs"
> > > > case?
> > > > Did you use oscilloscope for that?
> >
> > > Yes, I used and CSs was not asserted. Anyway, I will will try again.
> >
> > If the core chip select handling is not working properly for some reason
> > then the core chip select handling should be fixed rather than just open
> > coding in your driver - probably it's also broken for other users.
> >
>
> Hi Mark,
>
> I found the fix for cs-gpios. If I change spi_add_device function like
> this(see below) everything is ok.
>
> int spi_add_device(struct spi_device *spi)
>
> ...
>
> if (ctlr->cs_gpios){
> spi->cs_gpio = ctlr->cs_gpios[spi->chip_select];
> if(gpio_is_valid(spi->cs_gpio))
> gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
>
> }
>
> ...
>
> return status;
> }
>
> In the subsystem gpio direction of pins is never set and gpio_set_value()
> don't set the direction.
> In my opinion gpio_direction_output() set direction should be called in
> spi_add_device. What do you think? Is ok?
Back in 2014, I was suggesting using devm_gpio_request_one() in
of_spi_register_master(). That would take care of setting the direction
of the GPIO:
https://www.spinics.net/lists/arm-kernel/msg351251.html
I never took the time to create the patch and test though.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 8/8] PM / Domains: Stop deferring probe at the end of initcall
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
All PM domain drivers must be built-in (at least those using DT), so
there is no point deferring probe after initcalls are done. Continuing
to defer probe may prevent booting successfully even if managing PM
domains is not required. This can happen if the user failed to enable
the driver or if power-domains are added to a platform's DT, but there
is not yet a driver (e.g. a new DTB with an old kernel).
Call the driver core function driver_deferred_probe_check_init_done()
instead of just returning -EPROBE_DEFER to stop deferring probe when
initcalls are done.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <len.brown@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-pm at vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/base/power/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 1ea0e2502e8e..6398cf786e6a 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2218,7 +2218,7 @@ int genpd_dev_pm_attach(struct device *dev)
mutex_unlock(&gpd_list_lock);
dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
__func__, PTR_ERR(pd));
- return -EPROBE_DEFER;
+ return driver_deferred_probe_check_init_done(dev, true);
}
dev_dbg(dev, "adding to PM domain %s\n", pd->name);
--
2.17.0
^ permalink raw reply related
* [PATCH v2 7/8] iommu: Remove IOMMU_OF_DECLARE
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
Now that we use the driver core to stop deferred probe for missing
drivers, IOMMU_OF_DECLARE can be removed.
This is slightly less optimal than having a list of built-in drivers in
that we'll now defer probe twice before giving up. This shouldn't have a
significant impact on boot times as past discussions about deferred
probe have given no evidence of deferred probe having a substantial
impact.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: iommu at lists.linux-foundation.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-arm-msm at vger.kernel.org
Cc: linux-rockchip at lists.infradead.org
Cc: devicetree at vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/iommu/arm-smmu-v3.c | 2 --
drivers/iommu/arm-smmu.c | 7 -------
drivers/iommu/exynos-iommu.c | 2 --
drivers/iommu/ipmmu-vmsa.c | 3 ---
drivers/iommu/msm_iommu.c | 2 --
drivers/iommu/of_iommu.c | 19 +------------------
drivers/iommu/qcom_iommu.c | 2 --
drivers/iommu/rockchip-iommu.c | 2 --
include/linux/of_iommu.h | 4 ----
9 files changed, 1 insertion(+), 42 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 1d647104bccc..22bdabd3d8e0 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2915,8 +2915,6 @@ static struct platform_driver arm_smmu_driver = {
};
module_platform_driver(arm_smmu_driver);
-IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3");
-
MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60792a8..9dd7cbaa3b0c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2211,13 +2211,6 @@ static struct platform_driver arm_smmu_driver = {
};
module_platform_driver(arm_smmu_driver);
-IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1");
-IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2");
-IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
-IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
-IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
-IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2");
-
MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 85879cfec52f..b128cb4372d3 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1390,5 +1390,3 @@ static int __init exynos_iommu_init(void)
return ret;
}
core_initcall(exynos_iommu_init);
-
-IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu");
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 40ae6e87cb88..f026aa16d5f1 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -1108,9 +1108,6 @@ static void __exit ipmmu_exit(void)
subsys_initcall(ipmmu_init);
module_exit(ipmmu_exit);
-IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
-IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
-
MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 0d3350463a3f..27377742600d 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -877,7 +877,5 @@ static void __exit msm_iommu_driver_exit(void)
subsys_initcall(msm_iommu_driver_init);
module_exit(msm_iommu_driver_exit);
-IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu");
-
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Stepan Moskovchenko <stepanm@codeaurora.org>");
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 2aac8387717c..1904ccf9fc4e 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -27,9 +27,6 @@
#define NO_IOMMU 1
-static const struct of_device_id __iommu_of_table_sentinel
- __used __section(__iommu_of_table_end);
-
/**
* of_get_dma_window - Parse *dma-window property and returns 0 if found.
*
@@ -98,19 +95,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
}
EXPORT_SYMBOL_GPL(of_get_dma_window);
-static bool of_iommu_driver_present(struct device_node *np)
-{
- /*
- * If the IOMMU still isn't ready by the time we reach init, assume
- * it never will be. We don't want to defer indefinitely, nor attempt
- * to dereference __iommu_of_table after it's been freed.
- */
- if (system_state >= SYSTEM_RUNNING)
- return false;
-
- return of_match_node(&__iommu_of_table, np);
-}
-
static int of_iommu_xlate(struct device *dev,
struct of_phandle_args *iommu_spec)
{
@@ -120,8 +104,7 @@ static int of_iommu_xlate(struct device *dev,
ops = iommu_ops_from_fwnode(fwnode);
if ((ops && !ops->of_xlate) ||
- !of_device_is_available(iommu_spec->np) ||
- (!ops && !of_iommu_driver_present(iommu_spec->np)))
+ !of_device_is_available(iommu_spec->np))
return NO_IOMMU;
err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index 65b9c99707f8..fa0f6c39a144 100644
--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -947,7 +947,5 @@ static void __exit qcom_iommu_exit(void)
module_init(qcom_iommu_init);
module_exit(qcom_iommu_exit);
-IOMMU_OF_DECLARE(qcom_iommu_dev, "qcom,msm-iommu-v1");
-
MODULE_DESCRIPTION("IOMMU API for QCOM IOMMU v1 implementations");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 0468acfa131f..90d37f29c24c 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1284,8 +1284,6 @@ static int __init rk_iommu_init(void)
}
subsys_initcall(rk_iommu_init);
-IOMMU_OF_DECLARE(rk_iommu_of, "rockchip,iommu");
-
MODULE_DESCRIPTION("IOMMU API for Rockchip");
MODULE_AUTHOR("Simon Xue <xxm@rock-chips.com> and Daniel Kurtz <djkurtz@chromium.org>");
MODULE_ALIAS("platform:rockchip-iommu");
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 4fa654e4b5a9..f3d40dd7bb66 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -32,8 +32,4 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
#endif /* CONFIG_OF_IOMMU */
-extern struct of_device_id __iommu_of_table;
-
-#define IOMMU_OF_DECLARE(name, compat) OF_DECLARE_1(iommu, name, compat, NULL)
-
#endif /* __OF_IOMMU_H */
--
2.17.0
^ permalink raw reply related
* [PATCH v2 6/8] iommu: Stop deferring probe at end of initcalls
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
The IOMMU subsystem has its own mechanism to not defer probe if driver
support is missing. Now that the driver core supports stopping deferring
probe if drivers aren't built-in (and probed), use the driver core
support so the IOMMU specific support can be removed.
Cc: Joerg Roedel <joro@8bytes.org>
Cc: iommu at lists.linux-foundation.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/iommu/of_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b7656a..2aac8387717c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -133,7 +133,7 @@ static int of_iommu_xlate(struct device *dev,
* a proper probe-ordering dependency mechanism in future.
*/
if (!ops)
- return -EPROBE_DEFER;
+ return driver_deferred_probe_check_init_done(dev, true);
return ops->of_xlate(dev, iommu_spec);
}
--
2.17.0
^ permalink raw reply related
* [PATCH v2 5/8] pinctrl: optionally stop deferring probe at end of initcalls
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
If the pinctrl node in DT indicates that pin setup is optional and the
defaults can be used with the 'pinctrl-use-default', then only defer probe
until initcalls are done. This gives platforms the option to work without
their pinctrl driver being enabled.
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/pinctrl/devicetree.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index b601039d6c69..74a31074b406 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -110,17 +110,23 @@ static int dt_to_map_one_config(struct pinctrl *p,
int ret;
struct pinctrl_map *map;
unsigned num_maps;
+ bool pctl_optional = false;
/* Find the pin controller containing np_config */
np_pctldev = of_node_get(np_config);
for (;;) {
+ if (!pctl_optional)
+ pctl_optional = of_property_read_bool(np_pctldev, "pinctrl-use-default");
+
np_pctldev = of_get_next_parent(np_pctldev);
if (!np_pctldev || of_node_is_root(np_pctldev)) {
- dev_info(p->dev, "could not find pctldev for node %pOF, deferring probe\n",
- np_config);
of_node_put(np_pctldev);
- /* OK let's just assume this will appear later then */
- return -EPROBE_DEFER;
+ ret = driver_deferred_probe_check_init_done(p->dev, pctl_optional);
+ if (ret == -EPROBE_DEFER)
+ /* OK let's just assume this will appear later then */
+ dev_info(p->dev, "could not find pctldev for node %pOF, deferring probe\n",
+ np_config);
+ return ret;
}
/* If we're creating a hog we can use the passed pctldev */
if (pctldev && (np_pctldev == p->dev->of_node))
--
2.17.0
^ permalink raw reply related
* [PATCH v2 4/8] arm: dts: bcm283x: mark the UART pin muxing nodes with pinctrl-use-default
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/bcm283x.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index ac00e730f898..c8b8ede3d273 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -321,6 +321,7 @@
};
uart0_gpio14: uart0_gpio14 {
+ pinctrl-use-default;
brcm,pins = <14 15>;
brcm,function = <BCM2835_FSEL_ALT0>;
};
@@ -353,6 +354,7 @@
};
uart1_gpio14: uart1_gpio14 {
+ pinctrl-use-default;
brcm,pins = <14 15>;
brcm,function = <BCM2835_FSEL_ALT5>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH v2 3/8] dt-bindings: pinctrl: add a 'pinctrl-use-default' property
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
Pin setup may be optional in some cases such as the reset default works
or the pin setup is done by the bootloader. In these cases, it is optional
for the OS to support managing the pin controller and pin setup. In order
to support this scenario, add a property 'pinctrl-use-default' to indicate
that the pin configuration is optional.
Signed-off-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/pinctrl/pinctrl-bindings.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index ad9bbbba36e9..cef2b5855d60 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -103,6 +103,12 @@ Optional properties:
#pinctrl-cells: Number of pin control cells in addition to the index within the
pin controller device instance
+pinctrl-use-default: Boolean. Indicates that the OS can use the boot default
+ pin configuration. This allows using an OS that does not have a
+ driver for the pin controller. This property can be set either
+ globally for the pin controller or in child nodes for individual
+ pin group control.
+
Pin controller devices should contain the pin configuration nodes that client
devices reference.
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/8] driver core: add a deferred probe timeout
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
Deferring probe can wait forever on dependencies that may never appear
for a variety of reasons. This can be difficult to debug especially if
the console has dependencies or userspace fails to boot to a shell. Add
a timeout to retry probing without possibly optional dependencies and to
dump out the deferred probe pending list after retrying.
This mechanism is intended for debug purposes. It won't work for the
console which needs to be enabled before userspace starts. However, if
the console's dependencies are resolved, then the kernel log will be
printed (as opposed to no output).
Signed-off-by: Rob Herring <robh@kernel.org>
---
.../admin-guide/kernel-parameters.txt | 7 +++++
drivers/base/dd.c | 28 ++++++++++++++++++-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 11fc28ecdb6d..dd3f40b34a24 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -809,6 +809,13 @@
Defaults to the default architecture's huge page size
if not specified.
+ deferred_probe_timeout=
+ [KNL] Set a timeout in seconds for deferred probe to
+ give up waiting on dependencies to probe. Only specific
+ dependencies (subsystems or drivers) that have opted in
+ will be ignored. This option also dumps out devices
+ still on the deferred probe list after retrying.
+
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index d6034718da6f..4133b240c7e4 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -226,9 +226,17 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
}
+static int deferred_probe_timeout = -1;
+static int __init deferred_probe_timeout_setup(char *str)
+{
+ deferred_probe_timeout = simple_strtol(str, NULL, 0);
+ return 1;
+}
+__setup("deferred_probe_timeout=", deferred_probe_timeout_setup);
+
int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
{
- if (optional && initcalls_done) {
+ if ((optional || !deferred_probe_timeout) && initcalls_done) {
dev_WARN(dev, "ignoring dependency for device, assuming no driver");
return -ENODEV;
}
@@ -236,6 +244,19 @@ int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
return -EPROBE_DEFER;
}
+static void deferred_probe_timeout_work_func(struct work_struct *work)
+{
+ struct device_private *private, *p;
+
+ deferred_probe_timeout = 0;
+ driver_deferred_probe_trigger();
+ flush_work(&deferred_probe_work);
+
+ list_for_each_entry_safe(private, p, &deferred_probe_pending_list, deferred_probe)
+ dev_info(private->device, "deferred probe pending");
+}
+static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func);
+
/**
* deferred_probe_initcall() - Enable probing of deferred devices
*
@@ -257,6 +278,11 @@ static int deferred_probe_initcall(void)
*/
driver_deferred_probe_trigger();
flush_work(&deferred_probe_work);
+
+ if (deferred_probe_timeout > 0) {
+ schedule_delayed_work(&deferred_probe_timeout_work,
+ deferred_probe_timeout * HZ);
+ }
return 0;
}
late_initcall(deferred_probe_initcall);
--
2.17.0
^ permalink raw reply related
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
Deferred probe will currently wait forever on dependent devices to probe,
but sometimes a driver will never exist. It's also not always critical for
a driver to exist. Platforms can rely on default configuration from the
bootloader or reset defaults for things such as pinctrl and power domains.
This is often the case with initial platform support until various drivers
get enabled. There's at least 2 scenarios where deferred probe can render
a platform broken. Both involve using a DT which has more devices and
dependencies than the kernel supports. The 1st case is a driver may be
disabled in the kernel config. The 2nd case is the kernel version may
simply not have the dependent driver. This can happen if using a newer DT
(provided by firmware perhaps) with a stable kernel version.
Subsystems or drivers may opt-in to this behavior by calling
driver_deferred_probe_check_init_done() instead of just returning
-EPROBE_DEFER. They may use additional information from DT or kernel's
config to decide whether to continue to defer probe or not.
Cc: Alexander Graf <agraf@suse.de>
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/base/dd.c | 17 +++++++++++++++++
include/linux/device.h | 2 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index c9f54089429b..d6034718da6f 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -226,6 +226,16 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
}
+int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
+{
+ if (optional && initcalls_done) {
+ dev_WARN(dev, "ignoring dependency for device, assuming no driver");
+ return -ENODEV;
+ }
+
+ return -EPROBE_DEFER;
+}
+
/**
* deferred_probe_initcall() - Enable probing of deferred devices
*
@@ -240,6 +250,13 @@ static int deferred_probe_initcall(void)
/* Sort as many dependencies as possible before exiting initcalls */
flush_work(&deferred_probe_work);
initcalls_done = true;
+
+ /*
+ * Trigger deferred probe again, this time we won't defer anything
+ * that is optional
+ */
+ driver_deferred_probe_trigger();
+ flush_work(&deferred_probe_work);
return 0;
}
late_initcall(deferred_probe_initcall);
diff --git a/include/linux/device.h b/include/linux/device.h
index 477956990f5e..f3dafd44c285 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -334,6 +334,8 @@ struct device *driver_find_device(struct device_driver *drv,
struct device *start, void *data,
int (*match)(struct device *dev, void *data));
+int driver_deferred_probe_check_init_done(struct device *dev, bool optional);
+
/**
* struct subsys_interface - interfaces to device functions
* @name: name of the device function
--
2.17.0
^ permalink raw reply related
* [PATCH v2 0/8] Make deferring probe forever optional
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
This series came out of a discussion on the ARM boot-architecture
list[1] about DT forwards and backwards compatibility issues. There are
issues with newer DTs breaking on older, stable kernels. Some of these
are difficult to solve, but cases of optional devices not having
kernel support should be solvable.
I tested this on a RPi3 B with the pinctrl driver forced off. With this
change, the MMC/SD and UART drivers can function without the pinctrl
driver.
v2:
- Add a DT property for pinctrl to flag using defaults
- Add a debug timeout to stop deferring some number of seconds after
initcalls are done (giving modules a chance to load)
- Split pinctrl support to its own patch
- WARN when we stop deferring probe for a device
- Add IOMMU support
- Add PM domain support
Rob
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html
Rob Herring (8):
driver core: make deferring probe after init optional
driver core: add a deferred probe timeout
dt-bindings: pinctrl: add a 'pinctrl-use-default' property
arm: dts: bcm283x: mark the UART pin muxing nodes with
pinctrl-use-default
pinctrl: optionally stop deferring probe at end of initcalls
iommu: Stop deferring probe at end of initcalls
iommu: Remove IOMMU_OF_DECLARE
PM / Domains: Stop deferring probe at the end of initcall
.../admin-guide/kernel-parameters.txt | 7 +++
.../bindings/pinctrl/pinctrl-bindings.txt | 6 +++
arch/arm/boot/dts/bcm283x.dtsi | 2 +
drivers/base/dd.c | 43 +++++++++++++++++++
drivers/base/power/domain.c | 2 +-
drivers/iommu/arm-smmu-v3.c | 2 -
drivers/iommu/arm-smmu.c | 7 ---
drivers/iommu/exynos-iommu.c | 2 -
drivers/iommu/ipmmu-vmsa.c | 3 --
drivers/iommu/msm_iommu.c | 2 -
drivers/iommu/of_iommu.c | 21 +--------
drivers/iommu/qcom_iommu.c | 2 -
drivers/iommu/rockchip-iommu.c | 2 -
drivers/pinctrl/devicetree.c | 14 ++++--
include/linux/device.h | 2 +
include/linux/of_iommu.h | 4 --
16 files changed, 73 insertions(+), 48 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH] ARM: dts: pxa3xx: fix MMC clocks
From: Daniel Mack @ 2018-05-24 17:43 UTC (permalink / raw)
To: linux-arm-kernel
The clocks for the 3 MMC controllers on pxa3xx platforms are CLK_MMC1,
CLK_MMC2 and CLK_MMC3. CLK_MMC is only for pxa2xx.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
arch/arm/boot/dts/pxa3xx.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index 132cce03414f..7ffe06f1dcc0 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -174,7 +174,7 @@
compatible = "marvell,pxa-mmc";
reg = <0x41100000 0x1000>;
interrupts = <23>;
- clocks = <&clks CLK_MMC>;
+ clocks = <&clks CLK_MMC1>;
dmas = <&pdma 21 3
&pdma 22 3>;
dma-names = "rx", "tx";
@@ -185,7 +185,7 @@
compatible = "marvell,pxa-mmc";
reg = <0x42000000 0x1000>;
interrupts = <41>;
- clocks = <&clks CLK_MMC1>;
+ clocks = <&clks CLK_MMC2>;
dmas = <&pdma 93 3
&pdma 94 3>;
dma-names = "rx", "tx";
@@ -196,7 +196,7 @@
compatible = "marvell,pxa-mmc";
reg = <0x42500000 0x1000>;
interrupts = <55>;
- clocks = <&clks CLK_MMC2>;
+ clocks = <&clks CLK_MMC3>;
dmas = <&pdma 46 3
&pdma 47 3>;
dma-names = "rx", "tx";
--
2.14.3
^ permalink raw reply related
* [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions
From: Bjorn Andersson @ 2018-05-24 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1520347148-27852-2-git-send-email-sricharan@codeaurora.org>
On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> Krait CPUs have a handful of L2 cache controller registers that
> live behind a cp15 based indirection register. First you program
> the indirection register (l2cpselr) to point the L2 'window'
> register (l2cpdr) at what you want to read/write. Then you
> read/write the 'window' register to do what you want. The
> l2cpselr register is not banked per-cpu so we must lock around
> accesses to it to prevent other CPUs from re-pointing l2cpdr
> underneath us.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
This should have your signed-off-by here as well.
Apart from that:
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> arch/arm/common/Kconfig | 3 ++
> arch/arm/common/Makefile | 1 +
> arch/arm/common/krait-l2-accessors.c | 48 +++++++++++++++++++++++++++++++
> arch/arm/include/asm/krait-l2-accessors.h | 10 +++++++
> 4 files changed, 62 insertions(+)
> create mode 100644 arch/arm/common/krait-l2-accessors.c
> create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>
> diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
> index e5ad070..c8e1986 100644
> --- a/arch/arm/common/Kconfig
> +++ b/arch/arm/common/Kconfig
> @@ -7,6 +7,9 @@ config DMABOUNCE
> bool
> select ZONE_DMA
>
> +config KRAIT_L2_ACCESSORS
> + bool
> +
> config SHARP_LOCOMO
> bool
>
> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> index 70b4a14..eec6cd1 100644
> --- a/arch/arm/common/Makefile
> +++ b/arch/arm/common/Makefile
> @@ -7,6 +7,7 @@ obj-y += firmware.o
>
> obj-$(CONFIG_SA1111) += sa1111.o
> obj-$(CONFIG_DMABOUNCE) += dmabounce.o
> +obj-$(CONFIG_KRAIT_L2_ACCESSORS) += krait-l2-accessors.o
> obj-$(CONFIG_SHARP_LOCOMO) += locomo.o
> obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
> obj-$(CONFIG_SHARP_SCOOP) += scoop.o
> diff --git a/arch/arm/common/krait-l2-accessors.c b/arch/arm/common/krait-l2-accessors.c
> new file mode 100644
> index 0000000..9a97dda
> --- /dev/null
> +++ b/arch/arm/common/krait-l2-accessors.c
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018, The Linux Foundation. All rights reserved.
> +
> +#include <linux/spinlock.h>
> +#include <linux/export.h>
> +
> +#include <asm/barrier.h>
> +#include <asm/krait-l2-accessors.h>
> +
> +static DEFINE_RAW_SPINLOCK(krait_l2_lock);
> +
> +void krait_set_l2_indirect_reg(u32 addr, u32 val)
> +{
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(&krait_l2_lock, flags);
> + /*
> + * Select the L2 window by poking l2cpselr, then write to the window
> + * via l2cpdr.
> + */
> + asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
> + isb();
> + asm volatile ("mcr p15, 3, %0, c15, c0, 7 @ l2cpdr" : : "r" (val));
> + isb();
> +
> + raw_spin_unlock_irqrestore(&krait_l2_lock, flags);
> +}
> +EXPORT_SYMBOL(krait_set_l2_indirect_reg);
> +
> +u32 krait_get_l2_indirect_reg(u32 addr)
> +{
> + u32 val;
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(&krait_l2_lock, flags);
> + /*
> + * Select the L2 window by poking l2cpselr, then read from the window
> + * via l2cpdr.
> + */
> + asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
> + isb();
> + asm volatile ("mrc p15, 3, %0, c15, c0, 7 @ l2cpdr" : "=r" (val));
> +
> + raw_spin_unlock_irqrestore(&krait_l2_lock, flags);
> +
> + return val;
> +}
> +EXPORT_SYMBOL(krait_get_l2_indirect_reg);
> diff --git a/arch/arm/include/asm/krait-l2-accessors.h b/arch/arm/include/asm/krait-l2-accessors.h
> new file mode 100644
> index 0000000..dd7c474
> --- /dev/null
> +++ b/arch/arm/include/asm/krait-l2-accessors.h
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018, The Linux Foundation. All rights reserved.
> +
> +#ifndef __ASMARM_KRAIT_L2_ACCESSORS_H
> +#define __ASMARM_KRAIT_L2_ACCESSORS_H
> +
> +extern void krait_set_l2_indirect_reg(u32 addr, u32 val);
> +extern u32 krait_get_l2_indirect_reg(u32 addr);
> +
> +#endif
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH 3/4] KVM: arm/arm64: Remove unnecessary CMOs when creating HYP page tables
From: Mark Rutland @ 2018-05-24 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517103548.5622-4-marc.zyngier@arm.com>
On Thu, May 17, 2018 at 11:35:47AM +0100, Marc Zyngier wrote:
> There is no need to perform cache maintenance operations when
> creating the HYP page tables if we have the multiprocessing
> extensions. ARMv7 mandates them with the virtualization support,
> and ARMv8 just mandates them unconditionally.
>
> Let's remove these operations.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> virt/kvm/arm/mmu.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index ba66bf7ae299..acbfea09578c 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -578,7 +578,6 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
> pte = pte_offset_kernel(pmd, addr);
> kvm_set_pte(pte, pfn_pte(pfn, prot));
> get_page(virt_to_page(pte));
> - kvm_flush_dcache_to_poc(pte, sizeof(*pte));
> pfn++;
> } while (addr += PAGE_SIZE, addr != end);
> }
> @@ -605,7 +604,6 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
> }
> pmd_populate_kernel(NULL, pmd, pte);
> get_page(virt_to_page(pmd));
> - kvm_flush_dcache_to_poc(pmd, sizeof(*pmd));
> }
>
> next = pmd_addr_end(addr, end);
> @@ -638,7 +636,6 @@ static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
> }
> pud_populate(NULL, pud, pmd);
> get_page(virt_to_page(pud));
> - kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> }
>
> next = pud_addr_end(addr, end);
> @@ -675,7 +672,6 @@ static int __create_hyp_mappings(pgd_t *pgdp, unsigned long ptrs_per_pgd,
> }
> pgd_populate(NULL, pgd, pud);
> get_page(virt_to_page(pgd));
> - kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
> }
>
> next = pgd_addr_end(addr, end);
> @@ -685,6 +681,7 @@ static int __create_hyp_mappings(pgd_t *pgdp, unsigned long ptrs_per_pgd,
> pfn += (next - addr) >> PAGE_SHIFT;
> } while (addr = next, addr != end);
> out:
> + dsb(ishst);
I think you need a dsb(ishst) wherever you had a
kvm_flush_dcache_to_poc() previously.
Otherwise, the page table walker could see stale values. e.g. after you
update a bunch of PTE entries and point a PMD entry at those, the PTW
could see the updated PMD entry, but see stale PTE entries, which could
be garbage.
That said, I think for ensuring the *order* those become visible in, you
only need a dmb(ishst), and the ensure they *are visible* you need a
DSB(ISHST) at the end.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 2/6] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Guenter Roeck @ 2018-05-24 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <621dc488-2d8d-003b-9bd1-4de59e8d178b@broadcom.com>
On Thu, May 24, 2018 at 09:42:20AM -0700, Ray Jui wrote:
>
>
> On 5/24/2018 9:16 AM, Guenter Roeck wrote:
> >On Wed, May 23, 2018 at 05:15:20PM -0700, Ray Jui wrote:
> >>Update the SP805 binding document to add optional 'timeout-sec'
> >>devicetree property
> >>
> >>Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> >>---
> >> Documentation/devicetree/bindings/watchdog/arm,sp805.txt | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >>diff --git a/Documentation/devicetree/bindings/watchdog/arm,sp805.txt b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
> >>index 0fa3629..1debea3 100644
> >>--- a/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
> >>+++ b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
> >>@@ -19,6 +19,8 @@ Required properties:
> >> Optional properties:
> >> - interrupts: Should specify WDT interrupt number
> >>+- timeout-sec: Should specify default WDT timeout in seconds. If unset, the
> >>+ default timeout in the driver is 30 seconds
> >
> >"... the default timeout is determined by the driver" might be better.
> >If you want to mandate a default here (not sure if that is a good idea),
> >I would suggest to use something like "should be 30 seconds".
> >
>
> Okay. This can be changed to:
>
> - timeout-sec: Should specify default WDT timeout in seconds. If unset, the
> default timeout is determined by the driver.
>
> Please advise how to proceed with this patch series. Should I make the above
> modification and send out v4?
I would suggest to wait a day or two, then send out v4 if there are no further
comments.
Thanks,
Guenter
^ permalink raw reply
* [PATCH v3 4/6] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Guenter Roeck @ 2018-05-24 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e3d05f2-d526-9108-e2fd-13573458be85@broadcom.com>
On Thu, May 24, 2018 at 09:36:25AM -0700, Ray Jui wrote:
>
>
> On 5/24/2018 9:19 AM, Guenter Roeck wrote:
> >On Wed, May 23, 2018 at 05:15:22PM -0700, Ray Jui wrote:
> >>If the watchdog hardware is already enabled during the boot process,
> >>when the Linux watchdog driver loads, it should reset the watchdog and
> >>tell the watchdog framework. As a result, ping can be generated from
> >>the watchdog framework, until the userspace watchdog daemon takes over
> >>control
> >>
> >>Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> >>Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
> >>Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> >
> >Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> >
> >I have one question, though: Is it really correct that both
> >INT_ENABLE _and_ RESET_ENABLE have to be set to enable the watdog ?
> >What if only RESET_ENABLE is set ?
>
> According to the SP805 TRM, INT_ENABLE needs to be set to high to enable the
> counter and the interrupt. Counter will be stopped if INT_ENABLE is cleared.
> So yes, INT_ENABLE needs to be set.
>
Excellent, thanks for the clarification.
Guenter
^ permalink raw reply
* [PATCH v4 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-05-24 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524165045.GP8689@arm.com>
On Thu, May 24, 2018 at 05:50:48PM +0100, Will Deacon wrote:
> On Thu, May 24, 2018 at 04:55:17PM +0100, Dave Martin wrote:
> > On Thu, May 24, 2018 at 01:49:21PM +0100, Will Deacon wrote:
> > > On Wed, May 23, 2018 at 06:46:56PM +0100, Dave Martin wrote:
> > > > Stateful CPU architecture extensions may require the signal frame
> > > > to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
> > > > However, changing this #define is an ABI break.
> > > >
> > > > To allow userspace the option of determining the signal frame size
> > > > in a more forwards-compatible way, this patch adds a new auxv entry
> > > > tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
> > > > size that the process can observe during its lifetime.
> > > >
> > > > If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
> > > > assume that the MINSIGSTKSZ #define is sufficient. This allows for
> > > > a consistent interface with older kernels that do not provide
> > > > AT_MINSIGSTKSZ.
> > > >
> > > > The idea is that libc could expose this via sysconf() or some
> > > > similar mechanism.
> > > >
> > > > There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
> > > > about userspace's own stack overheads and should not pretend to
> > > > know.
> > >
> > > [...]
> > >
> > > > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > > > index fac1c4d..9c18f0e 100644
> > > > --- a/arch/arm64/include/asm/elf.h
> > > > +++ b/arch/arm64/include/asm/elf.h
> > > > @@ -121,6 +121,9 @@
> > > >
> > > > #ifndef __ASSEMBLY__
> > > >
> > > > +#include <linux/bug.h>
> > > > +#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
> > > > +
> > > > typedef unsigned long elf_greg_t;
> > > >
> > > > #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
> > > > @@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> > > > do { \
> > > > NEW_AUX_ENT(AT_SYSINFO_EHDR, \
> > > > (elf_addr_t)current->mm->context.vdso); \
> > > > + \
> > > > + /* \
> > > > + * Should always be nonzero unless there's a kernel bug. If \
> > > > + * the we haven't determined a sensible value to give to \
> > >
> > > "If the we"?
> >
> > Dang, fixed locally now.
> >
> > [...]
> >
> > > > diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
> > > > index ec0a86d..743c0b8 100644
> > > > --- a/arch/arm64/include/uapi/asm/auxvec.h
> > > > +++ b/arch/arm64/include/uapi/asm/auxvec.h
> > > > @@ -19,7 +19,8 @@
> > > >
> > > > /* vDSO location */
> > > > #define AT_SYSINFO_EHDR 33
> > > > +#define AT_MINSIGSTKSZ 51 /* stack needed for signal delivery */
> > >
> > > Curious: but how do we avoid/detect conflicts at -rc1? I guess somebody just
> > > needs to remember to run grep? (I know you have another series consolidating
> > > the ID allocations).
> >
> > We basically can't. These are spread over various arch headers today,
> > so the solution is to (a) grep, and (b) know that you needed to do that.
> >
> > This is the main motivation for collecting the definitions together.
> >
> > Short of having some script that checks these at build-time, I couldn't
> > see another obvious solution. It's nonetheless a bit ugly because of
> > things like AT_VECTOR_SIZE_ARCH which is masquerading a tag but isn't
> > one, and obviously does vary across arches...
> >
> > [...]
> >
> > > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> > > > index 154b7d3..00b9990 100644
> > > > --- a/arch/arm64/kernel/signal.c
> > > > +++ b/arch/arm64/kernel/signal.c
> >
> > [...]
> >
> > > > @@ -936,3 +949,28 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
> > > > thread_flags = READ_ONCE(current_thread_info()->flags);
> > > > } while (thread_flags & _TIF_WORK_MASK);
> > > > }
> > > > +
> > > > +unsigned long __ro_after_init signal_minsigstksz;
> > > > +
> > > > +/*
> > > > + * Determine the stack space required for guaranteed signal devliery.
> > > > + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> > > > + * cpufeatures setup is assumed to be complete.
> > > > + */
> > > > +void __init minsigstksz_setup(void)
> > > > +{
> > > > + struct rt_sigframe_user_layout user;
> > > > +
> > > > + init_user_layout(&user);
> > > > +
> > > > + /*
> > > > + * If this fails, SIGFRAME_MAXSZ needs to be enlarged. It won't
> > > > + * be big enough, but it's our best guess:
> > > > + */
> > > > + if (WARN_ON(setup_sigframe_layout(&user, true)))
> > > > + signal_minsigstksz = SIGFRAME_MAXSZ;
> > >
> > > Can we not leave signal_minsigstksz as zero in this case?
> >
> > I prefer to distinguish the "kernel went wrong" case (where we just omit
> > AT_MINSIGSTKSZ for backwards compatibilty) from the "sigframe too
> > large" case.
>
> Hmm, so I'm confused as to the distinction here. Wouldn't an allocation
> failure in setup_sigframe_layout be indicative of "kernel went wrong"?
>
> To put it another way, if we could determine the maximum sigframe size
> at build time, surely we'd fail the build if SIGFRAME_MAXSZ wasn't big
> enough? In that case, detecting this at runtime is also pretty bad (hence
Yup
> the WARN_ON) and I think we should drop the aux entry rather than provide
> a value that is known to be incorrect.
Telling userspace the signal frame size is not optional: by omitting
AT_MINSIGSTKSZ we implicitly tell userspace than MINSIGSTKSZ
is sufficient. But in this case we not only know that this is false, we
know that SIGFRAME_MAXSZ is not sufficient either. But we also know
that SIGFRAME_MAXSZ is a closer estimate to the true requirement, because
it's the larger value.
This falls under the heading of "being no more wrong than necessary".
Either way, this is trying to paper over a kernel bug, by telling
userspace something "sensible". This may not be a sensible course
of action...
So if you feel strongly I'm happy to not distinguish the two cases and
just WARN() in minsigstksz_setup() as at present.
Cheers
---Dave
^ 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