* [PATCH v2 08/10] PCI: Deprecate of_pci_get_host_bridge_resources()
From: Bjorn Helgaas @ 2018-05-08 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b13dd4b5-61c4-3acb-c194-3e448cb8b3d2@siemens.com>
On Thu, May 03, 2018 at 09:53:58AM +0200, Jan Kiszka wrote:
> On 2018-05-02 14:39, Christoph Hellwig wrote:
> > On Mon, Apr 30, 2018 at 07:48:42AM +0200, Jan Kiszka wrote:
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> There are no in-tree users remaining, all are converted to the managed
> >> variant. And it is unlikely that any out-of-tree user got the resource
> >> management right as well. So deprecate the interface and push users to
> >> the managed version instead.
> >>
> >> To avoid raising a warning when exporting a deprecated symbol, wrap the
> >> API with an inline and export an internal name.
> >
> > Don't deprecated it, just remove it.
>
> I see a clear favorite now: consider this patch obsolete. I'll send a
> separate removal patch, or a v3 of this series when otherwise needed.
Can you just send an update to this patch to remove it? I've got these on
a branch and will just update my branch with the removal.
Then I'll coordinate with Lorenzo and make sure the dependency issue is
resolved.
^ permalink raw reply
* [PATCH v3 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
From: Maxime Ripard @ 2018-05-08 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d8de7d2237a74388ac8c8152eded3477e7fd56a4.camel@paulk.fr>
On Mon, May 07, 2018 at 10:15:46PM +0200, Paul Kocialkowski wrote:
> > > + backlight: backlight {
> > > + compatible = "pwm-backlight";
> > > + pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
> > > + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
> >
> > The increase in perceived brightness should be linear. Usually, for
> > PWMs backed backlight, an exponential list is a much better
> > approximation.
>
> Thanks for the hint, it never occurred to me that pwm duty cycle was not
> linear with brightness, but that makes sense. I'll give that a try (on
> 255 values instead of 10 to keep some level of precision in low
> brightness). The way to go here is probably use a base-255 logarithm
> such as: duty cycle = range * log(i+1)/log(255) with i the linear
> brightness value (0 to 255) and range the amplitude of our values (that
> gets divided by the maximum brightness, so it's really up to hardware
> precision at this point). I'll go with a range of 255 as well.
Without going into something so complicated, usually a list with power
of two ending at 255 is a good approximation :)
> > > +&mmc0 {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&mmc0_pins_a>;
> > > + vmmc-supply = <®_vcc3v3>;
> >
> > You have the regulators described in your DT, you'd better use them
> > instead of the one coming from sunxi-common-regulators.dtsi.
>
> Well, according to the reference A20 design, the mmc pins and the card
> are powered by the 3.3V power rail, that comes from a regular step-down
> regulator sourcing from IPSOUT, so I don't see what regulator I should
> better use. Do you have a suggestion?
That works for me then.
> > > +&pio {
> > > + panel_power_pin: panel_power_pin at 0 {
> > > + pins = "PH8";
> > > + function = "gpio_out";
> > > + };
> > > +};
> >
> > You don't need that pinctrl node.
>
> I'll get rid of it then. You mentioned that regulator-simple uses the
> old GPIO API, so I assumed it meant that a pinctrl node is still needed.
> For reference, it uses of_get_named_gpio (not the devm-managed fashion).
This is only relevant for the polarity of the pins, not the pinctrl part.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] clk: imx6ull: use OSC clock during AXI rate change
From: Stefan Agner @ 2018-05-08 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB311395765D3DC03D5960DBA3879A0@HE1PR04MB3113.eurprd04.prod.outlook.com>
On 08.05.2018 09:32, Jacky Bai wrote:
>> Subject: Re: [PATCH] clk: imx6ull: use OSC clock during AXI rate change
>>
>> Hi Jacky,
>>
>> On 02.05.2018 09:38, Shawn Guo wrote:
>> > Hi Jacky,
>> >
>> > Do you see this problem on i.MX6 ULL? What's your take on Stefan's fix?
>>
>> Any comment to this?
>>
>> It is 4.17.0-rc4 is out and i.MX 6ULL is still broken :-(
>>
> Hi Stefan,
>
> I have tried two 6ULL board, I don't meet such issue. System can boot
> up successfully with commit 6f9575e55632 included.
> Anyway, the change in this patch is ok for me. it is no harm to the
> BUS clock change flow.
Hm, that is interesting, maybe it is because we use a different SKU? Or
maybe bootloader?
I tested here with a 800 MHz clocked variant on a Colibri iMX6ULL using
U-Boot 2016.11.
--
Stefan
>
> Jacky
>> --
>> Stefan
>>
>> >
>> > Shawn
>> >
>> > On Wed, Apr 18, 2018 at 02:49:08PM +0200, Stefan Agner wrote:
>> >> On i.MX6 ULL using PLL3 seems to cause a freeze when setting the
>> >> parent to IMX6UL_CLK_PLL3_USB_OTG. This only seems to appear since
>> >> commit 6f9575e55632 ("clk: imx: Add CLK_IS_CRITICAL flag for busy
>> >> divider and busy mux"), probably because the clock is now forced to
>> >> be on.
>> >>
>> >> Fixes: 6f9575e55632("clk: imx: Add CLK_IS_CRITICAL flag for busy
>> >> divider and busy mux")
>> >> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> >> ---
>> >> This addresses a regression ssen on v4.17-rc1 where the kernel boots
>> >> during clock initialization, see also:
>> >>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
>> >>
>> tchwork.kernel.org%2Fpatch%2F10295927%2F&data=02%7C01%7Cping.bai%
>> 40nx
>> >>
>> p.com%7C023287ec65034c4db45f08d5b419effb%7C686ea1d3bc2b4c6fa92cd9
>> 9c5c
>> >>
>> 301635%7C0%7C0%7C636612945852594725&sdata=U0ZGid9ZBey0FXfId2dhZb
>> hVl8p
>> >> CcjTiexG3JHYwCA4%3D&reserved=0
>> >>
>> >> drivers/clk/imx/clk-imx6ul.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/clk/imx/clk-imx6ul.c
>> >> b/drivers/clk/imx/clk-imx6ul.c index 114ecbb94ec5..12320118f8de
>> >> 100644
>> >> --- a/drivers/clk/imx/clk-imx6ul.c
>> >> +++ b/drivers/clk/imx/clk-imx6ul.c
>> >> @@ -464,7 +464,7 @@ static void __init imx6ul_clocks_init(struct
>> device_node *ccm_node)
>> >> clk_set_rate(clks[IMX6UL_CLK_AHB], 99000000);
>> >>
>> >> /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz
>> */
>> >> - clk_set_parent(clks[IMX6UL_CLK_PERIPH_CLK2_SEL],
>> clks[IMX6UL_CLK_PLL3_USB_OTG]);
>> >> + clk_set_parent(clks[IMX6UL_CLK_PERIPH_CLK2_SEL],
>> >> +clks[IMX6UL_CLK_OSC]);
>> >> clk_set_parent(clks[IMX6UL_CLK_PERIPH],
>> clks[IMX6UL_CLK_PERIPH_CLK2]);
>> >> clk_set_parent(clks[IMX6UL_CLK_PERIPH_PRE],
>> clks[IMX6UL_CLK_PLL2_BUS]);
>> >> clk_set_parent(clks[IMX6UL_CLK_PERIPH],
>> >> clks[IMX6UL_CLK_PERIPH_PRE]);
>> >> --
>> >> 2.17.0
>> >>
^ permalink raw reply
* [PATCH v9 00/12] Sunxi: Add SMP support on A83T
From: Maxime Ripard @ 2018-05-08 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504190545.5114-1-mylene.josserand@bootlin.com>
Hi,
On Fri, May 04, 2018 at 09:05:33PM +0200, Myl?ne Josserand wrote:
> Hello everyone,
>
> This is a V9 of my series that adds SMP support for Allwinner sun8i-a83t.
> Based on sunxi's tree, sunxi/for-next branch.
> Depends on a patch from Doug Berger that allows to include the "cpu-type"
> header on assembly files that I included in my series (patch 01).
I applied the patches, with the remarks done by Russell on v8 fixed,
and the function sun8i_a83t_cntvoff_init made static.
> The difference with the v8 is just that the machine is renamed in sun8i-a83t
> (see patch 07), according to Maxime's review.
The machine name hasn't changed, and the name sun8i-a83t still doesn't
make much sense. I've fixed it as well.
Thanks,
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 1/2] arm64: dts: ls1012a: Add FRWY-LS1012A board support
From: Fabio Estevam @ 2018-05-08 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525760999-6187-1-git-send-email-Bhaskar.Upadhaya@nxp.com>
Hi Bhaskar,
On Tue, May 8, 2018 at 3:29 AM, Bhaskar Upadhaya
<Bhaskar.Upadhaya@nxp.com> wrote:
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
> @@ -0,0 +1,64 @@
Please consider using:
// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Device Tree file for NXP LS1012A FRWY Board.
> + *
> + * Copyright 2018 NXP
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
Then you can replace all the licensing text.
^ permalink raw reply
* [RESEND PATCH v2] bus: arm-cci: use asm unreachable
From: Stefan Agner @ 2018-05-08 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9925be9a-2e24-7ab4-4d7e-cb8f62c422e7@arm.com>
On 08.05.2018 14:19, Robin Murphy wrote:
> On 08/05/18 12:32, Stefan Agner wrote:
>> Mixing asm and C code is not recommended in a naked function by
>> gcc and leads to an error when using clang:
>> drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked
>> function is not supported
>> unreachable();
>> ^
>>
>> While the function is marked __naked it actually properly return
>> in asm. There is no need for the unreachable() call.
>
> The commit title is a bit out-of-date now (I guess it could just be
> something like "remove unnecessary unreachable()" now), but the rest
> looks OK to me - even GCC clearly doesn't expect anything beyond the
> asm to be reachable anyway since the lack of epilogue includes the
> lack of any compiler-generated return. I've checked that GCC 7.2
> generates identical object files before and after, other than (for
> obvious reasons) the line numbers generated by WANT_WARN_ON_SLOWPATH
> for all the WARN()s appearing later in the file.
Title: Oops, good catch! Will send a v3.
Thanks for checking gcc.
--
Stefan
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
>> Suggested-by: Russell King <linux@arm.linux.org.uk>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> Acked-by: Nicolas Pitre <nico@linaro.org>
>> ---
>> drivers/bus/arm-cci.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
>> index 443e4c3fd357..b8184a903583 100644
>> --- a/drivers/bus/arm-cci.c
>> +++ b/drivers/bus/arm-cci.c
>> @@ -371,8 +371,6 @@ asmlinkage void __naked cci_enable_port_for_self(void)
>> [sizeof_struct_cpu_port] "i" (sizeof(struct cpu_port)),
>> [sizeof_struct_ace_port] "i" (sizeof(struct cci_ace_port)),
>> [offsetof_port_phys] "i" (offsetof(struct cci_ace_port, phys)) );
>> -
>> - unreachable();
>> }
>> /**
>>
^ permalink raw reply
* [PATCH] Kirin-PCIe: Add kirin pcie msi feature.
From: Bjorn Helgaas @ 2018-05-08 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525763028-107417-1-git-send-email-chenyao11@huawei.com>
[+cc Stanimir, Jianguo, Shawn for qcom, histb comments below]
On Tue, May 08, 2018 at 03:03:48PM +0800, Yao Chen wrote:
> This patch adds kirin pcie msi feature.
Thanks for the patch! Please update your subject and changelog like this:
PCI: kirin: Add MSI support
Add support for MSI.
You can figure out what style to use for the subject by running:
git log --oneline drivers/pci/dwc/pcie-kirin.c
Then follow the existing style.
> Signed-off-by: Yao Chen <chenyao11@huawei.com>
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 ++
> drivers/pci/dwc/pcie-kirin.c | 38 +++++++++++++++++++++++++++++++
> 2 files changed, 40 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index ec3eb8e..4ef684f 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -872,6 +872,8 @@
> 0x0 0x02000000>;
> num-lanes = <1>;
> #interrupt-cells = <1>;
> + interrupts = <0 283 4>;
> + interrupts-names = "msi";
> interrupt-map-mask = <0xf800 0 0 7>;
> interrupt-map = <0x0 0 0 1
> &gic GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>,
> diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
> index d2970a0..2319c9c 100644
> --- a/drivers/pci/dwc/pcie-kirin.c
> +++ b/drivers/pci/dwc/pcie-kirin.c
> @@ -426,9 +426,28 @@ static int kirin_pcie_establish_link(struct pcie_port *pp)
> return 0;
> }
>
> +static irqreturn_t kirin_pcie_msi_irq_handler(int irq, void *arg)
> +{
> + struct pcie_port *pp = arg;
> +
> + return dw_handle_msi_irq(pp);
> +}
> +
> +static void kirin_pcie_msi_init(struct pcie_port *pp)
> +{
> + dw_pcie_msi_init(pp);
> +}
> +
> +static void kirin_pcie_enable_interrupts(struct pcie_port *pp)
> +{
> + if (IS_ENABLED(CONFIG_PCI_MSI))
> + kirin_pcie_msi_init(pp);
> +}
> +
> static int kirin_pcie_host_init(struct pcie_port *pp)
> {
> kirin_pcie_establish_link(pp);
> + kirin_pcie_enable_interrupts(pp);
>
> return 0;
> }
> @@ -448,6 +467,25 @@ static int kirin_pcie_host_init(struct pcie_port *pp)
> static int __init kirin_add_pcie_port(struct dw_pcie *pci,
> struct platform_device *pdev)
> {
> + int ret;
> +
> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> + pci->pp.msi_irq = platform_get_irq(pdev, 0);
> + if (!pci->pp.msi_irq) {
> + dev_err(&pdev->dev, "failed to get msi irq\n");
s/msi irq/MSI IRQ/
> + return -ENODEV;
> + }
> + ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
> + kirin_pcie_msi_irq_handler,
> + IRQF_SHARED | IRQF_NO_THREAD,
> + "kirin_pcie_msi", &pci->pp);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to request msi irq\n");
s/msi irq/MSI IRQ/
Also, please include the IRQ number (pci->pp.msi_irq) in the message.
> + return ret;
> + }
> + }
> +
> + pci->pp.root_bus_nr = -1;
Setting root_bus_nr looks like an unrelated change that should be in a
separate patch.
But I'm not sure why you need to set root_bus_nr at all, since
dw_pcie_host_init() always sets it.
Some other callers of dw_pcie_host_init() do set it:
exynos_add_pcie_port()
imx6_add_pcie_port()
armada8k_add_pcie_port()
artpec6_add_pcie_port()
dw_plat_add_pcie_port()
histb_pcie_probe()
qcom_pcie_probe()
spear13xx_add_pcie_port()
But I don't see *why* any of these need to set it. If they don't need to
set it, they shouldn't.
And it would be nice if histb and qcom followed the structure and naming
conventions of the other drivers, i.e., they should have
histb_add_pcie_port() and qcom_add_pcie_port().
> pci->pp.ops = &kirin_pcie_host_ops;
>
> return dw_pcie_host_init(&pci->pp);
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
From: Russell King - ARM Linux @ 2018-05-08 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505205242.GA2876@lunn.ch>
On Sat, May 05, 2018 at 10:52:42PM +0200, Andrew Lunn wrote:
> On Sat, May 05, 2018 at 01:38:31PM -0700, Florian Fainelli wrote:
> > On May 4, 2018 10:14:25 AM PDT, Andrew Lunn <andrew@lunn.ch> wrote:
> > >On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote:
> > >> On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> > >> > In case no Tx disable pin is available the SFP modules will always
> > >be
> > >> > emitting. This could be an issue when using modules using laser as
> > >their
> > >> > light source as we would have no way to disable it when the fiber
> > >is
> > >> > removed. This patch adds a warning when registering an SFP cage
> > >which do
> > >> > not have its tx_disable pin wired or available.
> > >>
> > >> Is this something that was done in a possibly earlier revision of a
> > >> given board design and which was finally fixed? Nothing wrong with
> > >the
> > >> patch, but this seems like a pretty serious board design mistake,
> > >that
> > >> needs to be addressed.
> > >
> > >Hi Florian
> > >
> > >Zii Devel B is like this. Only the "Signal Detect" pin is wired to a
> > >GPIO.
> >
>
> > Good point, indeed. BTW what do you think about exposing the SFF's
> > EEPROM and diagnostics through the standard ethtool operations even
> > if we have to keep the description of the SFF as a fixed link in
> > Device Tree because of the unfortunate wiring?
>
> I believe in Antoine case, all the control plane is broken. He cannot
> read the EEPROM, nor any of the modules pins via GPIOs.
Correct.
> For Zii Devel B, the EEPROM is accessible, and so is the SD pin. What
> is missing is transmit disable. So i would expose it as an SFF module.
Agreed.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] tty: pl011: Avoid spuriously stuck-off interrupts
From: Dave Martin @ 2018-05-08 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508110119.GA16141@n2100.armlinux.org.uk>
On Tue, May 08, 2018 at 12:01:19PM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 27, 2018 at 11:05:45AM +0100, Dave Martin wrote:
> > Commit 9b96fbacda34 ("serial: PL011: clear pending interrupts")
> > clears the RX and receive timeout interrupts on pl011 startup, to
> > avoid a screaming-interrupt scenario that can occur when the
> > firmware or bootloader leaves these interrupts asserted.
> >
> > This has been noted as an issue when running Linux on qemu [1].
> >
> > Unfortunately, the above fix seems to lead to potential
> > misbehaviour if the RX FIFO interrupt is asserted _non_ spuriously
> > on driver startup, if the RX FIFO is also already full to the
> > trigger level.
> >
> > Clearing the RX FIFO interrupt does not change the FIFO fill level.
> > In this scenario, because the interrupt is now clear and because
> > the FIFO is already full to the trigger level, no new assertion of
> > the RX FIFO interrupt can occur unless the FIFO is drained back
> > below the trigger level. This never occurs because the pl011
> > driver is waiting for an RX FIFO interrupt to tell it that there is
> > something to read, and does not read the FIFO at all until that
> > interrupt occurs.
> >
> > Thus, simply clearing "spurious" interrupts on startup may be
> > misguided, since there is no way to be sure that the interrupts are
> > truly spurious, and things can go wrong if they are not.
> >
> > This patch instead clears the interrupt condition by draining the
> > RX FIFO during UART startup, after clearing any potentially
> > spurious interrupt. This should ensure that an interrupt will
> > definitely be asserted if the RX FIFO subsequently becomes
> > sufficiently full.
> >
> > The drain is done at the point of enabling interrupts only. This
> > means that it will occur any time the UART is newly opened through
> > the tty layer. It will not apply to polled-mode use of the UART by
> > kgdboc: since that scenario cannot use interrupts by design, this
> > should not matter. kgdboc will interact badly with "normal" use of
> > the UART in any case: this patch makes no attempt to paper over
> > such issues.
> >
> > This patch does not attempt to address the case where the RX FIFO
> > fills faster than it can be drained: that is a pathological
> > hardware design problem that is beyond the scope of the driver to
> > work around.
> >
> > [1] [Qemu-devel] [Qemu-arm] [PATCH] pl011: do not put into fifo
> > before enabled the interruption
> > https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg06446.html
> >
> > Reported-by: Wei Xu <xuwei5@hisilicon.com>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Fixes: 9b96fbacda34 ("serial: PL011: clear pending interrupts")
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > Tested-by: Andrew Jones <drjones@redhat.com>
> > Reviewed-by: Andrew Jones <drjones@redhat.com>
> > ---
> > drivers/tty/serial/amba-pl011.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> > index 4b40a5b..a6ccb85 100644
> > --- a/drivers/tty/serial/amba-pl011.c
> > +++ b/drivers/tty/serial/amba-pl011.c
> > @@ -1731,6 +1731,16 @@ static void pl011_enable_interrupts(struct uart_amba_port *uap)
> >
> > /* Clear out any spuriously appearing RX interrupts */
> > pl011_write(UART011_RTIS | UART011_RXIS, uap, REG_ICR);
> > +
> > + /*
> > + * RXIS is asserted only when the RX FIFO transitions from below
> > + * to above the trigger threshold. If the RX FIFO is already
> > + * full to the threshold this can't happen and RXIS will now be
> > + * stuck off. Drain the RX FIFO explicitly to fix this:
> > + */
> > + while (!(pl011_read(uap, REG_FR) & UART01x_FR_RXFE))
> > + pl011_read(uap, REG_DR);
>
> You probably ought to limit this in case of a stuck receive not empty
> case, maybe to (eg) twice the depth of the FIFO?
My argument would have been that if the FIFO fills too fast to be
drained, then you have more serious problems... but it would be better
for this to show as character loss than a lockup.
So, I guess draining twice the FIFO depth before giving up is a
reasonable compromise.
I'll hack that in and repost.
Cheers
---Dave
^ permalink raw reply
* [PATCH v9 01/12] ARM: Allow this header to be included by assembly files
From: Russell King - ARM Linux @ 2018-05-08 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504190545.5114-2-mylene.josserand@bootlin.com>
On Fri, May 04, 2018 at 09:05:34PM +0200, Myl?ne Josserand wrote:
> From: Doug Berger <opendmb@gmail.com>
>
> The constants defined in this file are equally useful in assembly and C
> source files. The arm64 architecture version of this file allows
> inclusion in both assembly and C source files, so this this commit adds
> that capability to the arm architecture version so that the constants
> don't need to be defined in multiple places.
>
> Signed-off-by: Doug Berger <opendmb@gmail.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Myl?ne Josserand <mylene.josserand@bootlin.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
> ---
> arch/arm/include/asm/cputype.h | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index cb546425da8a..e7632f536633 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -2,9 +2,6 @@
> #ifndef __ASM_ARM_CPUTYPE_H
> #define __ASM_ARM_CPUTYPE_H
>
> -#include <linux/stringify.h>
> -#include <linux/kernel.h>
> -
> #define CPUID_ID 0
> #define CPUID_CACHETYPE 1
> #define CPUID_TCM 2
> @@ -98,6 +95,11 @@
> /* Qualcomm implemented cores */
> #define ARM_CPU_PART_SCORPION 0x510002d0
>
> +#ifndef __ASSEMBLY__
> +
> +#include <linux/stringify.h>
> +#include <linux/kernel.h>
> +
> extern unsigned int processor_id;
>
> #ifdef CONFIG_CPU_CP15
> @@ -326,4 +328,6 @@ static inline int __attribute_const__ cpuid_feature_extract_field(u32 features,
> #define cpuid_feature_extract(reg, field) \
> cpuid_feature_extract_field(read_cpuid_ext(reg), field)
>
> +#endif /* __ASSEMBLY__ */
> +
> #endif
> --
> 2.11.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set
From: Russell King - ARM Linux @ 2018-05-08 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180305102524.5905-3-o.rempel@pengutronix.de>
On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote:
> One of the Freescale recommended sequences for power off with external
> PMIC is the following:
> ...
> 3. SoC is programming PMIC for power off when standby is asserted.
> 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
>
> See:
> http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
> page 5083
>
> This patch implements step 4. of this sequence.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> arch/arm/mach-imx/pm-imx6.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
> index ecdf071653d4..24689260a2a5 100644
> --- a/arch/arm/mach-imx/pm-imx6.c
> +++ b/arch/arm/mach-imx/pm-imx6.c
> @@ -604,6 +604,28 @@ static void __init imx6_pm_common_init(const struct imx6_pm_socdata
> IMX6Q_GPR1_GINT);
> }
>
> +static void imx6_pm_stby_poweroff(void)
> +{
> + imx6_set_lpm(STOP_POWER_OFF);
> + cpu_suspend(0, imx6q_suspend_finish);
Do you actually need to save the processor state etc here - the request
is after all to power down the system and not to suspend. Would calling
imx6q_suspend_finish() directly work (and hence simplify the code) ?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v5 10/14] KVM: arm64: Save host SVE context as appropriate
From: Dave Martin @ 2018-05-08 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ab34071f-1808-f33a-e9a0-3067afa815af@arm.com>
On Tue, May 08, 2018 at 12:57:56PM +0100, Marc Zyngier wrote:
> On 08/05/18 12:25, Dave Martin wrote:
> > On Tue, May 08, 2018 at 11:38:05AM +0100, Marc Zyngier wrote:
> >> On 04/05/18 17:05, Dave Martin wrote:
> >>> This patch adds SVE context saving to the hyp FPSIMD context switch
> >>> path. This means that it is no longer necessary to save the host
> >>> SVE state in advance of entering the guest, when in use.
> >>>
> >>> In order to avoid adding pointless complexity to the code, VHE is
> >>> assumed if SVE is in use. VHE is an architectural prerequisite for
> >>> SVE, so there is no good reason to turn CONFIG_ARM64_VHE off in
> >>> kernels that support both SVE and KVM.
> >>>
> >>> Historically, software models exist that can expose the
> >>> architecturally invalid configuration of SVE without VHE, so if
> >>> this situation is detected this patch warns and refuses to create a
> >>> VM. Doing this check at VM creation time avoids race issues
> >>> between KVM and SVE initialisation.
> >>>
> >>> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> >>> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> >>> ---
> >>> arch/arm64/Kconfig | 7 +++++++
> >>> arch/arm64/kvm/fpsimd.c | 1 -
> >>> arch/arm64/kvm/hyp/switch.c | 21 +++++++++++++++++++--
> >>> virt/kvm/arm/arm.c | 18 ++++++++++++++++++
> >>> 4 files changed, 44 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >>> index eb2cf49..b0d3820 100644
> >>> --- a/arch/arm64/Kconfig
> >>> +++ b/arch/arm64/Kconfig
> >>> @@ -1130,6 +1130,7 @@ endmenu
> >>> config ARM64_SVE
> >>> bool "ARM Scalable Vector Extension support"
> >>> default y
> >>> + depends on !KVM || ARM64_VHE
> >>
> >> In that case, should we consider making ARM64_VHE "default y" as well,
> >> as KVM is "default y" too?
> >
> > Surely ARM64_VHE has always been default y?
> >
> > 1f364c8c48a0 ("arm64: VHE: Add support for running Linux in EL2 mode")
>
> Hmmm. I have no idea who this Zyngier guy from 2014 is. Oh well.
>
> >> Otherwise, I fear we end-up regressing existing configurations. Also,
> >> you still have to check for the configuration at run time, so I'm not
> >> immediately getting the point of this particular change.
> >
> > We check for the configuration, but the penalty is severe (i.e., can't
> > create VMs) and it doesn't appear to make sense to put effort into
> > working around that: the user has an easy fix in the form of setting
> > ARM64_VHE=y.
> >
> > Is there some value to supporting this configuration that I'm missing?
> > SVE and VHE are both default y.
>
> I had the (obviously wrong) idea that VHE didn't default to y.
Fair enough.
[...]
> >>> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> >>> index 6cf499b..a7be7bf 100644
> >>> --- a/virt/kvm/arm/arm.c
> >>> +++ b/virt/kvm/arm/arm.c
> >>> @@ -16,6 +16,7 @@
> >>> * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
> >>> */
> >>>
> >>> +#include <linux/bug.h>
> >>> #include <linux/cpu_pm.h>
> >>> #include <linux/errno.h>
> >>> #include <linux/err.h>
> >>> @@ -41,6 +42,7 @@
> >>> #include <asm/mman.h>
> >>> #include <asm/tlbflush.h>
> >>> #include <asm/cacheflush.h>
> >>> +#include <asm/cpufeature.h>
> >>> #include <asm/virt.h>
> >>> #include <asm/kvm_arm.h>
> >>> #include <asm/kvm_asm.h>
> >>> @@ -120,6 +122,22 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> >>> if (type)
> >>> return -EINVAL;
> >>>
> >>> + /*
> >>> + * VHE is a prerequisite for SVE in the Arm architecture, and
> >>> + * Kconfig ensures that if system_supports_sve() here then
> >>> + * CONFIG_ARM64_VHE is enabled, so if VHE support wasn't already
> >>> + * detected and enabled, the CPU is architecturally
> >>> + * noncompliant.
> >>> + *
> >>> + * Just in case this mismatch is seen, detect it, warn and give
> >>> + * up. Supporting this forbidden configuration in Hyp would be
> >>> + * pointless.
> >>> + */
> >>> + if (system_supports_sve() && !has_vhe()) {
> >>> + kvm_pr_unimpl("Cannot create VMs on SVE system without VHE. Broken cpu?");
> >>> + return -ENXIO;
> >>> + }
> >>
> >> You might as well fail the boot KVM initialization altogether, and not
> >> wait for a VM to be created.
> >
> > I was concerned that the SVE and KVM initialisation might happen in
> > an unpredictable order.
> >
> > KVM is initialised via module_init(), which I'm guessing is later than
> > cpufeatures (?) If so then yes, kvm_arch_init() would be a reasonable
> > place to do this.
>
> CPU features are set in stone very early, right after we've booted all
> the CPUs that can be discovered before running userspace. KVM itself
> relies on that, so you should be able to move that check pretty early.
OK, I'll have a go.
> >> But I'm more concerned with the fact that we're now have a configuration
> >> that drops functionalities on the floor, one way or another.
> >
> > Is this still a problem if that configuration is forbidden by Kconfig?
> >
> > Can you describe a scenario in which the problem config (KVM=y, VHE=n,
> > SVE=y) would be wanted?
>
> Not really. I guess it is just me being paranoid and not realising we
> had VHE on by default already.
OK, I'll leave it as-is for now, but give me a shout if you have further
concerns.
Cheers
---Dave
^ permalink raw reply
* [PATCH net-next v2 06/13] phy: add 2.5G SGMII mode to the phy_mode enum
From: Russell King - ARM Linux @ 2018-05-08 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135643.23466-7-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:36PM +0200, Antoine Tenart wrote:
> This patch adds one more generic PHY mode to the phy_mode enum, to allow
> configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
> callback.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Hi,
Would it be possible to get the 2.5G SGMII comphy support merged
ahead of the rest of this series please - I don't think there's been
any objections to it, and having it in mainline would then mean I can
drop the Marvell Comphy code from my tree and transition to the bootlin
Comphy code instead.
Of course, the perfect solution would be to get the whole series merged,
but I'm just thinking about the situation where we're still discussing
points when the next merge window opens.
Thanks.
> ---
> include/linux/phy/phy.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index c9d14eeee7f5..9713aebdd348 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -36,6 +36,7 @@ enum phy_mode {
> PHY_MODE_USB_DEVICE_SS,
> PHY_MODE_USB_OTG,
> PHY_MODE_SGMII,
> + PHY_MODE_2500SGMII,
> PHY_MODE_10GKR,
> PHY_MODE_UFS_HS_A,
> PHY_MODE_UFS_HS_B,
> --
> 2.17.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v5 13/14] KVM: arm64: Fold redundant exit code checks out of fixup_guest_exit()
From: Dave Martin @ 2018-05-08 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5b9460e5-207d-befd-446c-b9c7ec2bcc35@arm.com>
On Tue, May 08, 2018 at 12:59:39PM +0100, Marc Zyngier wrote:
> On 08/05/18 12:30, Dave Martin wrote:
> > On Tue, May 08, 2018 at 11:59:25AM +0100, Marc Zyngier wrote:
> >> On 04/05/18 17:05, Dave Martin wrote:
[...]
> >>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> >>> index 39e9166..be09c52 100644
> >>> --- a/arch/arm64/kvm/hyp/switch.c
> >>> +++ b/arch/arm64/kvm/hyp/switch.c
> >>> @@ -385,11 +385,13 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> >>> * same PC once the SError has been injected, and replay the
> >>> * trapping instruction.
> >>> */
> >>> - if (*exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
> >>> + if (*exit_code != ARM_EXCEPTION_TRAP)
> >>> + goto exit;
> >>> +
> >>> + if (!__populate_fault_info(vcpu))
> >>> return true;
> >>>
> >>> - if (static_branch_unlikely(&vgic_v2_cpuif_trap) &&
> >>> - *exit_code == ARM_EXCEPTION_TRAP) {
> >>> + if (static_branch_unlikely(&vgic_v2_cpuif_trap)) {
> >>> bool valid;
> >>>
> >>> valid = kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_DABT_LOW &&
> >>> @@ -414,12 +416,12 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> >>> if (!__skip_instr(vcpu))
> >>> *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
> >>> *exit_code = ARM_EXCEPTION_EL1_SERROR;
> >>> + goto exit;
> >>
> >> This goto...
> >>
> >>> }
> >>
> >> ... should be placed here. If this was a data abort, it cannot be a
> >> system register trap, and the below conditions cannot possibly apply.
> >
> > That sounds logically sensible, but to be clear, this would be a
> > semantic change to this function, right?
> >
> > (i.e., it forces skipping of the GICv3 handling code in a case where
> > it previously wasn't forced -- at least not within this function. The
> > arguments about whether vgic_v2_cpuif_trap and vgic_v3_cpuif_trap can
> > ever be true simultaneously still apply.)
>
> I agree that this is a slight semantic change, but one that makes sense,
> just like the one you've introduced in patch #12.
Agreed, just wanted to make sure I hadn't missed something in my
original refactoring.
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-05-08 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508122652.3zbgvpx7x2al5g5m@lakrids.cambridge.arm.com>
On Tue, May 08, 2018 at 01:26:52PM +0100, Mark Rutland wrote:
> On Tue, May 08, 2018 at 12:43:24PM +0100, Dave Martin wrote:
> > On Tue, May 08, 2018 at 12:30:44PM +0100, Mark Rutland wrote:
> > > On Tue, May 08, 2018 at 11:43:30AM +0100, Dave Martin wrote:
> > > > +/*
> > > > + * Determine the stack space required for guaranteed signal devliery.
> > > > + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> > > > + */
> > > > +int get_minsigstksz(void)
> > > > +{
> > > > + static __read_mostly atomic_t minsigstksz;
> > > > +
> > > > + int ret;
> > > > + struct rt_sigframe_user_layout user;
> > > > +
> > > > + ret = atomic_read(&minsigstksz);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + init_user_layout(&user);
> > > > + ret = setup_sigframe_layout(&user, true);
> > > > +
> > > > + if (ret) {
> > > > + WARN_ON(1);
> > > > +
> > > > + ret = SIGSTKSZ;
> > > > + } else {
> > > > + ret = sigframe_size(&user) +
> > > > + round_up(sizeof(struct frame_record), 16) +
> > > > + 16; /* max alignment padding */
> > > > + }
> > > > +
> > > > + /*
> > > > + * The computed value (ret) is invariant, so its value can be
> > > > + * safely stored irrespective of whether some other racing
> > > > + * task got there first:
> > > > + */
> > > > + atomic_set(&minsigstksz, ret);
> > > > + return ret;
> > > > +}
> > >
> > > Can we set up minsigstksz at some initcall time? that way get_minstksz()
> > > can return minsigstksz with no conditionality at all.
> >
> > I would have preferred to do that, but I wasn't sure where to put it.
> >
> > Unless arch_initcall_sync() works for this, I don't know what to
> > suggest.
>
> Perhaps have a setup_minsigstksz(), and call that at the end of
> setup_cpu_features()?
That's probably reasonable. The places the computed value can change
are ... not well defined, if the dust hasn't settled by the time we get
to the end of the cpufeatures setup then we almost certainly have more
serious problems.
I'll have a go and see what it looks like.
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/2] arm64: signal: Report signal frame size to userspace via auxv
From: Mark Rutland @ 2018-05-08 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508114323.GG7753@e103592.cambridge.arm.com>
On Tue, May 08, 2018 at 12:43:24PM +0100, Dave Martin wrote:
> On Tue, May 08, 2018 at 12:30:44PM +0100, Mark Rutland wrote:
> > On Tue, May 08, 2018 at 11:43:30AM +0100, Dave Martin wrote:
> > > +/*
> > > + * Determine the stack space required for guaranteed signal devliery.
> > > + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> > > + */
> > > +int get_minsigstksz(void)
> > > +{
> > > + static __read_mostly atomic_t minsigstksz;
> > > +
> > > + int ret;
> > > + struct rt_sigframe_user_layout user;
> > > +
> > > + ret = atomic_read(&minsigstksz);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + init_user_layout(&user);
> > > + ret = setup_sigframe_layout(&user, true);
> > > +
> > > + if (ret) {
> > > + WARN_ON(1);
> > > +
> > > + ret = SIGSTKSZ;
> > > + } else {
> > > + ret = sigframe_size(&user) +
> > > + round_up(sizeof(struct frame_record), 16) +
> > > + 16; /* max alignment padding */
> > > + }
> > > +
> > > + /*
> > > + * The computed value (ret) is invariant, so its value can be
> > > + * safely stored irrespective of whether some other racing
> > > + * task got there first:
> > > + */
> > > + atomic_set(&minsigstksz, ret);
> > > + return ret;
> > > +}
> >
> > Can we set up minsigstksz at some initcall time? that way get_minstksz()
> > can return minsigstksz with no conditionality at all.
>
> I would have preferred to do that, but I wasn't sure where to put it.
>
> Unless arch_initcall_sync() works for this, I don't know what to
> suggest.
Perhaps have a setup_minsigstksz(), and call that at the end of
setup_cpu_features()?
Thanks,
Mark.
^ permalink raw reply
* [RESEND PATCH v2] bus: arm-cci: use asm unreachable
From: Robin Murphy @ 2018-05-08 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508113211.7026-1-stefan@agner.ch>
On 08/05/18 12:32, Stefan Agner wrote:
> Mixing asm and C code is not recommended in a naked function by
> gcc and leads to an error when using clang:
> drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked
> function is not supported
> unreachable();
> ^
>
> While the function is marked __naked it actually properly return
> in asm. There is no need for the unreachable() call.
The commit title is a bit out-of-date now (I guess it could just be
something like "remove unnecessary unreachable()" now), but the rest
looks OK to me - even GCC clearly doesn't expect anything beyond the asm
to be reachable anyway since the lack of epilogue includes the lack of
any compiler-generated return. I've checked that GCC 7.2 generates
identical object files before and after, other than (for obvious
reasons) the line numbers generated by WANT_WARN_ON_SLOWPATH for all the
WARN()s appearing later in the file.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Suggested-by: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> drivers/bus/arm-cci.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> index 443e4c3fd357..b8184a903583 100644
> --- a/drivers/bus/arm-cci.c
> +++ b/drivers/bus/arm-cci.c
> @@ -371,8 +371,6 @@ asmlinkage void __naked cci_enable_port_for_self(void)
> [sizeof_struct_cpu_port] "i" (sizeof(struct cpu_port)),
> [sizeof_struct_ace_port] "i" (sizeof(struct cci_ace_port)),
> [offsetof_port_phys] "i" (offsetof(struct cci_ace_port, phys)) );
> -
> - unreachable();
> }
>
> /**
>
^ permalink raw reply
* [PATCH v5 13/14] KVM: arm64: Fold redundant exit code checks out of fixup_guest_exit()
From: Marc Zyngier @ 2018-05-08 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508113039.GF7753@e103592.cambridge.arm.com>
On 08/05/18 12:30, Dave Martin wrote:
> On Tue, May 08, 2018 at 11:59:25AM +0100, Marc Zyngier wrote:
>> On 04/05/18 17:05, Dave Martin wrote:
>>> The entire tail of fixup_guest_exit() is contained in if statements
>>> of the form if (x && *exit_code == ARM_EXCEPTION_TRAP). As a result,
>>> we can check just once and bail out of the function early, allowing
>>> the remaining if conditions to be simplified.
>>>
>>> The only awkward case is where *exit_code is changed to
>>> ARM_EXCEPTION_EL1_SERROR in the case of an illegal GICv2 CPU
>>> interface access: in that case, the GICv3 trap handling code is
>>> skipped using a goto. This avoids pointlessly evaluating the
>>> static branch check for the GICv3 case, even though we can't have
>>> vgic_v2_cpuif_trap and vgic_v3_cpuif_trap true simultaneously
>>> unless we have a GICv3 and GICv2 on the host: that sounds stupid,
>>> but I haven't satisfied myself that it can't happen.
>>
>> Indeed, this cannot happen, unless we decided to trap access to the
>> memory-mapped interface of a GICv3 implementation. We don't do that.
>>
>> But I guess the goto also serves a visual clue that the two cases are
>> mutually exclusives. Small nit below though:
>>
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
>>> ---
>>> arch/arm64/kvm/hyp/switch.c | 11 +++++++----
>>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>>> index 39e9166..be09c52 100644
>>> --- a/arch/arm64/kvm/hyp/switch.c
>>> +++ b/arch/arm64/kvm/hyp/switch.c
>>> @@ -385,11 +385,13 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
>>> * same PC once the SError has been injected, and replay the
>>> * trapping instruction.
>>> */
>>> - if (*exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
>>> + if (*exit_code != ARM_EXCEPTION_TRAP)
>>> + goto exit;
>>> +
>>> + if (!__populate_fault_info(vcpu))
>>> return true;
>>>
>>> - if (static_branch_unlikely(&vgic_v2_cpuif_trap) &&
>>> - *exit_code == ARM_EXCEPTION_TRAP) {
>>> + if (static_branch_unlikely(&vgic_v2_cpuif_trap)) {
>>> bool valid;
>>>
>>> valid = kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_DABT_LOW &&
>>> @@ -414,12 +416,12 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
>>> if (!__skip_instr(vcpu))
>>> *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
>>> *exit_code = ARM_EXCEPTION_EL1_SERROR;
>>> + goto exit;
>>
>> This goto...
>>
>>> }
>>
>> ... should be placed here. If this was a data abort, it cannot be a
>> system register trap, and the below conditions cannot possibly apply.
>
> That sounds logically sensible, but to be clear, this would be a
> semantic change to this function, right?
>
> (i.e., it forces skipping of the GICv3 handling code in a case where
> it previously wasn't forced -- at least not within this function. The
> arguments about whether vgic_v2_cpuif_trap and vgic_v3_cpuif_trap can
> ever be true simultaneously still apply.)
I agree that this is a slight semantic change, but one that makes sense,
just like the one you've introduced in patch #12.
Thanks,
N,
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v5 10/14] KVM: arm64: Save host SVE context as appropriate
From: Marc Zyngier @ 2018-05-08 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508112514.GE7753@e103592.cambridge.arm.com>
On 08/05/18 12:25, Dave Martin wrote:
> On Tue, May 08, 2018 at 11:38:05AM +0100, Marc Zyngier wrote:
>> On 04/05/18 17:05, Dave Martin wrote:
>>> This patch adds SVE context saving to the hyp FPSIMD context switch
>>> path. This means that it is no longer necessary to save the host
>>> SVE state in advance of entering the guest, when in use.
>>>
>>> In order to avoid adding pointless complexity to the code, VHE is
>>> assumed if SVE is in use. VHE is an architectural prerequisite for
>>> SVE, so there is no good reason to turn CONFIG_ARM64_VHE off in
>>> kernels that support both SVE and KVM.
>>>
>>> Historically, software models exist that can expose the
>>> architecturally invalid configuration of SVE without VHE, so if
>>> this situation is detected this patch warns and refuses to create a
>>> VM. Doing this check at VM creation time avoids race issues
>>> between KVM and SVE initialisation.
>>>
>>> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
>>> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
>>> ---
>>> arch/arm64/Kconfig | 7 +++++++
>>> arch/arm64/kvm/fpsimd.c | 1 -
>>> arch/arm64/kvm/hyp/switch.c | 21 +++++++++++++++++++--
>>> virt/kvm/arm/arm.c | 18 ++++++++++++++++++
>>> 4 files changed, 44 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index eb2cf49..b0d3820 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -1130,6 +1130,7 @@ endmenu
>>> config ARM64_SVE
>>> bool "ARM Scalable Vector Extension support"
>>> default y
>>> + depends on !KVM || ARM64_VHE
>>
>> In that case, should we consider making ARM64_VHE "default y" as well,
>> as KVM is "default y" too?
>
> Surely ARM64_VHE has always been default y?
>
> 1f364c8c48a0 ("arm64: VHE: Add support for running Linux in EL2 mode")
Hmmm. I have no idea who this Zyngier guy from 2014 is. Oh well.
>> Otherwise, I fear we end-up regressing existing configurations. Also,
>> you still have to check for the configuration at run time, so I'm not
>> immediately getting the point of this particular change.
>
> We check for the configuration, but the penalty is severe (i.e., can't
> create VMs) and it doesn't appear to make sense to put effort into
> working around that: the user has an easy fix in the form of setting
> ARM64_VHE=y.
>
> Is there some value to supporting this configuration that I'm missing?
> SVE and VHE are both default y.
I had the (obviously wrong) idea that VHE didn't default to y.
>
> [...]
>
>>> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
>>> index 6cf499b..a7be7bf 100644
>>> --- a/virt/kvm/arm/arm.c
>>> +++ b/virt/kvm/arm/arm.c
>>> @@ -16,6 +16,7 @@
>>> * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
>>> */
>>>
>>> +#include <linux/bug.h>
>>> #include <linux/cpu_pm.h>
>>> #include <linux/errno.h>
>>> #include <linux/err.h>
>>> @@ -41,6 +42,7 @@
>>> #include <asm/mman.h>
>>> #include <asm/tlbflush.h>
>>> #include <asm/cacheflush.h>
>>> +#include <asm/cpufeature.h>
>>> #include <asm/virt.h>
>>> #include <asm/kvm_arm.h>
>>> #include <asm/kvm_asm.h>
>>> @@ -120,6 +122,22 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>>> if (type)
>>> return -EINVAL;
>>>
>>> + /*
>>> + * VHE is a prerequisite for SVE in the Arm architecture, and
>>> + * Kconfig ensures that if system_supports_sve() here then
>>> + * CONFIG_ARM64_VHE is enabled, so if VHE support wasn't already
>>> + * detected and enabled, the CPU is architecturally
>>> + * noncompliant.
>>> + *
>>> + * Just in case this mismatch is seen, detect it, warn and give
>>> + * up. Supporting this forbidden configuration in Hyp would be
>>> + * pointless.
>>> + */
>>> + if (system_supports_sve() && !has_vhe()) {
>>> + kvm_pr_unimpl("Cannot create VMs on SVE system without VHE. Broken cpu?");
>>> + return -ENXIO;
>>> + }
>>
>> You might as well fail the boot KVM initialization altogether, and not
>> wait for a VM to be created.
>
> I was concerned that the SVE and KVM initialisation might happen in
> an unpredictable order.
>
> KVM is initialised via module_init(), which I'm guessing is later than
> cpufeatures (?) If so then yes, kvm_arch_init() would be a reasonable
> place to do this.
CPU features are set in stone very early, right after we've booted all
the CPUs that can be discovered before running userspace. KVM itself
relies on that, so you should be able to move that check pretty early.
>> But I'm more concerned with the fact that we're now have a configuration
>> that drops functionalities on the floor, one way or another.
>
> Is this still a problem if that configuration is forbidden by Kconfig?
>
> Can you describe a scenario in which the problem config (KVM=y, VHE=n,
> SVE=y) would be wanted?
Not really. I guess it is just me being paranoid and not realising we
had VHE on by default already.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v0 2/2] arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
From: Heiko Stuebner @ 2018-05-08 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525747704-8537-3-git-send-email-djw@t-chip.com.cn>
Hi Levin,
Am Dienstag, 8. Mai 2018, 04:48:24 CEST schrieb djw at t-chip.com.cn:
> From: Levin Du <djw@t-chip.com.cn>
>
> In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
> the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
> controlled by a special output only gpio pin.
>
> However, this pin, not being a normal gpio in the rockchip pinctrl,
> is set by bit 1 of system register GRF_SOC_CON10. Therefore a new
> gpio controller using gpio-syscon driver is defined in order to use
> regulator-gpio.
>
> If the signal voltage changes, the io domain needs to change
> correspondingly.
>
> To use this feature, the following options are required in kernel config:
> - CONFIG_GPIO_SYSCON=y
> - CONFIG_POWER_AVS=y
> - CONFIG_ROCKCHIP_IODOMAIN=y
>
> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>
> ---
>
> arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 36 ++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
> index 246c317..792cb04 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
> @@ -14,6 +14,12 @@
> stdout-path = "serial2:1500000n8";
> };
>
> + gpio_syscon10: gpio-syscon10 {
> + compatible = "rockchip,rk3328-gpio-syscon10";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
please split this into a separate patch, move it to rk3328.dtsi and together
with the suggestions from patch 1/2 make it look like
grf: syscon at ff100000 {
compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
reg = <0x0 0xff100000 0x0 0x1000>;
...
gpio_mute: gpio-mute {
compatible = "rockchip,rk3328-gpio-mute";
gpio-controller;
#gpio-cells = <2>;
};
...
};
So making the gpio-controller a child of the grf node.
And as this definition is not specific to the roc-cc it should be in the
main devicetree file for the rk3328.
> gmac_clkin: external-gmac-clock {
> compatible = "fixed-clock";
> clock-frequency = <125000000>;
> @@ -41,6 +47,19 @@
> vin-supply = <&vcc_io>;
> };
>
> + vcc_sdio: sdmmcio-regulator {
> + compatible = "regulator-gpio";
> + gpios = <&gpio_syscon10 1 GPIO_ACTIVE_HIGH>;
> + states = <1800000 0x1
> + 3300000 0x0>;
> + regulator-name = "vcc_sdio";
> + regulator-type = "voltage";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + vin-supply = <&vcc_sys>;
> + };
> +
> vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
> compatible = "regulator-fixed";
> enable-active-high;
> @@ -208,6 +227,18 @@
> };
> };
>
> +&io_domains {
> + status = "okay";
> +
> + vccio1-supply = <&vcc_io>;
> + vccio2-supply = <&vcc18_emmc>;
> + vccio3-supply = <&vcc_sdio>;
> + vccio4-supply = <&vcc_18>;
> + vccio5-supply = <&vcc_io>;
> + vccio6-supply = <&vcc_io>;
> + pmuio-supply = <&vcc_io>;
> +};
> +
Please split this into a separate patch about
"adding io-domain supplies for roc-cc"
> &pinctrl {
> pmic {
> pmic_int_l: pmic-int-l {
> @@ -227,10 +258,15 @@
> cap-mmc-highspeed;
> cap-sd-highspeed;
> disable-wp;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
please sort properties alphabetically, so between pinctrl-0 and vmmc-supply
> max-frequency = <150000000>;
> pinctrl-names = "default";
> pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>;
> vmmc-supply = <&vcc_sd>;
> + vqmmc-supply = <&vcc_sdio>;
> status = "okay";
> };
Thanks
Heiko
^ permalink raw reply
* [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
From: Russell King - ARM Linux @ 2018-05-08 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135643.23466-4-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:33PM +0200, Antoine Tenart wrote:
> In case no Tx disable pin is available the SFP modules will always be
> emitting. This could be an issue when using modules using laser as their
> light source as we would have no way to disable it when the fiber is
> removed. This patch adds a warning when registering an SFP cage which do
> not have its tx_disable pin wired or available.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Looks fine, thanks.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> drivers/net/phy/sfp.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> index 8e323a4b70da..d4f503b2e3e2 100644
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
> @@ -1093,6 +1093,15 @@ static int sfp_probe(struct platform_device *pdev)
> if (!sfp->gpio[GPIO_MODDEF0] && !sfp->gpio[GPIO_LOS])
> sfp->sm_dev_state = SFP_DEV_UNKNOWN;
>
> + /* We could have an issue in cases no Tx disable pin is available or
> + * wired as modules using a laser as their light source will continue to
> + * be active when the fiber is removed. This could be a safety issue and
> + * we should at least warn the user about that.
> + */
> + if (!sfp->gpio[GPIO_TX_DISABLE])
> + dev_warn(sfp->dev,
> + "No tx_disable pin: SFP modules will always be emitting.\n");
> +
> return 0;
> }
>
> --
> 2.17.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Russell King - ARM Linux @ 2018-05-08 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135643.23466-3-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote:
> SFP connectors can be solder on a board without having any of their pins
> (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> and the overall link status reporting is left to other layers.
>
> In order to achieve this, a new SFP_DEV status is added, named UNKNOWN.
> This mode is set when it is not possible for the SFP code to get the
> link status and as a result the link status is reported to be always UP
> from the SFP point of view.
This looks weird to me. SFP_DEV_* states track the netdevice up/down
state and have little to do with whether LOS or MODDEF0 are implemented.
I think it would be better to have a new SFP_MOD_* and to force
sm_mod_state to that in this circumstance.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH REPOST] ARM: smp: Move clear_tasks_mm_cpumask() call to __cpu_die()
From: Russell King - ARM Linux @ 2018-05-08 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504112939.25493-1-bigeasy@linutronix.de>
On Fri, May 04, 2018 at 01:29:39PM +0200, Sebastian Andrzej Siewior wrote:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
>
> Suspending a CPU on a RT kernel results in the following backtrace:
>
> | Disabling non-boot CPUs ...
> | BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
> | in_atomic(): 1, irqs_disabled(): 128, pid: 18, name: migration/1
> | INFO: lockdep is turned off.
> | irq event stamp: 122
> | hardirqs last enabled at (121): [<c06ac0ac>] _raw_spin_unlock_irqrestore+0x88/0x90
> | hardirqs last disabled at (122): [<c06abed0>] _raw_spin_lock_irq+0x28/0x5c
> | CPU: 1 PID: 18 Comm: migration/1 Tainted: G W 4.1.4-rt3-01046-g96ac8da #204
> | Hardware name: Generic DRA74X (Flattened Device Tree)
> | [<c0019134>] (unwind_backtrace) from [<c0014774>] (show_stack+0x20/0x24)
> | [<c0014774>] (show_stack) from [<c06a70f4>] (dump_stack+0x88/0xdc)
> | [<c06a70f4>] (dump_stack) from [<c006cab8>] (___might_sleep+0x198/0x2a8)
> | [<c006cab8>] (___might_sleep) from [<c06ac4dc>] (rt_spin_lock+0x30/0x70)
> | [<c06ac4dc>] (rt_spin_lock) from [<c013f790>] (find_lock_task_mm+0x9c/0x174)
> | [<c013f790>] (find_lock_task_mm) from [<c00409ac>] (clear_tasks_mm_cpumask+0xb4/0x1ac)
> | [<c00409ac>] (clear_tasks_mm_cpumask) from [<c00166a4>] (__cpu_disable+0x98/0xbc)
> | [<c00166a4>] (__cpu_disable) from [<c06a2e8c>] (take_cpu_down+0x1c/0x50)
> | [<c06a2e8c>] (take_cpu_down) from [<c00f2600>] (multi_cpu_stop+0x11c/0x158)
> | [<c00f2600>] (multi_cpu_stop) from [<c00f2a9c>] (cpu_stopper_thread+0xc4/0x184)
> | [<c00f2a9c>] (cpu_stopper_thread) from [<c0069058>] (smpboot_thread_fn+0x18c/0x324)
> | [<c0069058>] (smpboot_thread_fn) from [<c00649c4>] (kthread+0xe8/0x104)
> | [<c00649c4>] (kthread) from [<c0010058>] (ret_from_fork+0x14/0x3c)
> | CPU1: shutdown
>
> The root cause of above backtrace is task_lock() which takes a sleeping
> lock on -RT.
>
> To fix the issue, move clear_tasks_mm_cpumask() call from __cpu_disable()
> to __cpu_die() which is called on the thread which is asking for a target
> CPU to be shutdown. In addition, this change restores CPU hotplug
> functionality on ARM CPU1 can be unplugged/plugged many times.
This looks fine to me - all the paths that use the mm_cpumask() check
that the CPU is still marked online.
Please send to the patch system, thanks.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Cc: <linux-arm-kernel@lists.infradead.org>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Link: http://lkml.kernel.org/r/1441995683-30817-1-git-send-email-grygorii.strashko at ti.com
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> [bigeasy: slighty edited the commit message]
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> arch/arm/kernel/smp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -236,8 +236,6 @@ int __cpu_disable(void)
> flush_cache_louis();
> local_flush_tlb_all();
>
> - clear_tasks_mm_cpumask(cpu);
> -
> return 0;
> }
>
> @@ -255,6 +253,7 @@ void __cpu_die(unsigned int cpu)
> }
> pr_debug("CPU%u: shutdown\n", cpu);
>
> + clear_tasks_mm_cpumask(cpu);
> /*
> * platform_cpu_kill() is generally expected to do the powering off
> * and/or cutting of clocks to the dying CPU. Optionally, this may
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 8/8] arm64: tegra: Mark tcu as primary serial port on Tegra194 P2888
From: Mikko Perttunen @ 2018-05-08 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508114403.14499-1-mperttunen@nvidia.com>
The Tegra Combined UART is the proper primary serial port on P2888,
so use it.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
index 859ab5af17c1..95e2433984f7 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -10,7 +10,7 @@
aliases {
sdhci0 = "/cbb/sdhci at 3460000";
sdhci1 = "/cbb/sdhci at 3400000";
- serial0 = &uartb;
+ serial0 = &tcu;
i2c0 = "/bpmp/i2c";
i2c1 = "/cbb/i2c at 3160000";
i2c2 = "/cbb/i2c at c240000";
--
2.16.1
^ permalink raw reply related
* [PATCH 7/8] arm64: tegra: Add nodes for tcu on Tegra194
From: Mikko Perttunen @ 2018-05-08 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508114403.14499-1-mperttunen@nvidia.com>
Add nodes required for communication through the Tegra Combined UART.
This includes the AON HSP instance, addition of shared interrupts
for the TOP0 HSP instance, and finally the TCU node itself. Also
mark the HSP instances as compatible to tegra194-hsp, as the hardware
is not identical but is compatible to tegra186-hsp.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 34 +++++++++++++++++++++++++++++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 6d699815a84f..d7f780b06fe2 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -217,10 +217,31 @@
};
hsp_top0: hsp at 3c00000 {
- compatible = "nvidia,tegra186-hsp";
+ compatible = "nvidia,tegra194-hsp", "nvidia,tegra186-hsp";
reg = <0x03c00000 0xa0000>;
- interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "doorbell";
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "doorbell", "shared0", "shared1", "shared2",
+ "shared3", "shared4", "shared5", "shared6",
+ "shared7";
+ #mbox-cells = <2>;
+ };
+
+ hsp_aon: hsp at c150000 {
+ compatible = "nvidia,tegra194-hsp", "nvidia,tegra186-hsp";
+ reg = <0x0c150000 0xa0000>;
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "shared0", "shared1", "shared2", "shared3";
#mbox-cells = <2>;
};
@@ -382,6 +403,13 @@
};
};
+ tcu: tcu {
+ compatible = "nvidia,tegra194-tcu";
+ mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_SM 0>,
+ <&hsp_aon TEGRA_HSP_MBOX_TYPE_SM 1>;
+ mbox-names = "rx", "tx";
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13
--
2.16.1
^ 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