* Re: [PATCH v2 3/3] arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1
From: Jagan Teki @ 2018-12-06 16:18 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, linux-kernel, Chen-Yu Tsai, Rob Herring,
Michael Trimarchi, linux-amarula, linux-arm-kernel
In-Reply-To: <20181206153532.6c756gccmpuj4wdw@flea>
On Thu, Dec 6, 2018 at 9:05 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Thu, Dec 06, 2018 at 06:53:06PM +0530, Jagan Teki wrote:
> > Some camera modules have the SoC feeding a master clock to the sensor
> > instead of having a standalone crystal. This clock signal is generated
> > from the clock control unit and output from the CSI MCLK function of
> > pin PE1.
> >
> > Add a pinmux setting for it for camera sensors to reference.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > Changes for v2:
> > - new patch
> >
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index d7ab0006ebce..902b5238f1dd 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -538,6 +538,11 @@
> > function = "csi0";
> > };
> >
> > + csi_mclk_pin: csi-mclk {
> > + pins = "PE1";
> > + function = "csi0";
> > + };
> > +
>
> We're not merging nodes that have no users.
Yes, v1 [1] has a consumer for this. Since it's under discussion about
PE group supply, opendrain I hold it. will send once the discussion
done, I even tested on top-of your ov5640 changes.
[1] https://patchwork.kernel.org/patch/10709077/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 24/25] firmware: arm_sdei: Add ACPI GHES registration helper
From: Catalin Marinas @ 2018-12-06 16:18 UTC (permalink / raw)
To: James Morse
Cc: Tony Luck, Fan Wu, Xie XiuQi, Marc Zyngier, Will Deacon,
Rafael Wysocki, Christoffer Dall, Dongjiu Geng, linux-mm,
linux-acpi, Borislav Petkov, Naoya Horiguchi, kvmarm,
linux-arm-kernel, Len Brown
In-Reply-To: <20181203180613.228133-25-james.morse@arm.com>
On Mon, Dec 03, 2018 at 06:06:12PM +0000, James Morse wrote:
> APEI's Generic Hardware Error Source structures do not describe
> whether the SDEI event is shared or private, as this information is
> discoverable via the API.
>
> GHES needs to know whether an event is normal or critical to avoid
> sharing locks or fixmap entries, but GHES shouldn't have to know about
> the SDEI API.
>
> Add a helper to register the GHES using the appropriate normal or
> critical callback.
>
> Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 23/25] arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
From: Catalin Marinas @ 2018-12-06 16:18 UTC (permalink / raw)
To: James Morse
Cc: Tony Luck, Fan Wu, Xie XiuQi, Marc Zyngier, Will Deacon,
Rafael Wysocki, Christoffer Dall, Dongjiu Geng, linux-mm,
linux-acpi, Borislav Petkov, Naoya Horiguchi, kvmarm,
linux-arm-kernel, Len Brown
In-Reply-To: <20181203180613.228133-24-james.morse@arm.com>
On Mon, Dec 03, 2018 at 06:06:11PM +0000, James Morse wrote:
> APEI is unable to do all of its error handling work in nmi-context, so
> it defers non-fatal work onto the irq_work queue. arch_irq_work_raise()
> sends an IPI to the calling cpu, but this is not guaranteed to be taken
> before returning to user-space.
>
> Unless the exception interrupted a context with irqs-masked,
> irq_work_run() can run immediately. Otherwise return -EINPROGRESS to
> indicate ghes_notify_sea() found some work to do, but it hasn't
> finished yet.
>
> With this apei_claim_sea() returning '0' means this external-abort was
> also notification of a firmware-first RAS error, and that APEI has
> processed the CPER records.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
> Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
> CC: Xie XiuQi <xiexiuqi@huawei.com>
> CC: gengdongjiu <gengdongjiu@huawei.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: WIP: UFS on apq8098
From: Marc Gonzalez @ 2018-12-06 16:15 UTC (permalink / raw)
To: Jeffrey Hugo, Bjorn Andersson, Nicolas Dechesne, Andy Gross,
Stephen Boyd
Cc: MSM, Linux ARM
In-Reply-To: <7a7ccedd-c6b2-6789-c76e-ad2ddcd53e2a@codeaurora.org>
On 04/12/2018 18:31, Jeffrey Hugo wrote:
> From what I can tell from the documentation, this is sourced from
> ufs_unipro_core_clk_src, which is inturn sourced from gpll0_out_main.
> I'm guessing gcc-msm8998.c needs to be updated to reflect this. It
> would also be good to check this against the downstream kernel.
With Stephen's "define xo clock" patch applied:
# cat clk_summary
enable prepare protect duty
clock count count count rate accuracy phase cycle
---------------------------------------------------------------------------------------------
gcc_usb_phy_cfg_ahb2phy_clk 0 0 0 0 0 0 50000
gcc_usb3_phy_pipe_clk 0 0 0 0 0 0 50000
gcc_usb30_sleep_clk 0 0 0 0 0 0 50000
gcc_ufs_tx_symbol_0_clk 0 0 0 0 0 0 50000
gcc_ufs_rx_symbol_1_clk 0 0 0 0 0 0 50000
gcc_ufs_rx_symbol_0_clk 0 0 0 0 0 0 50000
gcc_ufs_phy_aux_clk 0 0 0 0 0 0 50000
gcc_ufs_ice_core_clk 0 0 0 0 0 0 50000
gcc_ufs_ahb_clk 0 0 0 0 0 0 50000
gcc_tsif_inactivity_timers_clk 0 0 0 0 0 0 50000
gcc_tsif_ahb_clk 0 0 0 0 0 0 50000
gcc_sdcc4_ahb_clk 0 0 0 0 0 0 50000
gcc_sdcc2_ahb_clk 0 0 0 0 0 0 50000
gcc_prng_ahb_clk 0 0 0 0 0 0 50000
gcc_pdm_xo4_clk 0 0 0 0 0 0 50000
gcc_pdm_ahb_clk 0 0 0 0 0 0 50000
gcc_pcie_0_slv_axi_clk 0 0 0 0 0 0 50000
gcc_pcie_0_pipe_clk 0 0 0 0 0 0 50000
gcc_pcie_0_mstr_axi_clk 0 0 0 0 0 0 50000
gcc_pcie_0_cfg_ahb_clk 0 0 0 0 0 0 50000
gcc_mss_at_clk 0 0 0 0 0 0 50000
gcc_mmss_sys_noc_axi_clk 0 0 0 0 0 0 50000
gcc_mmss_qm_core_clk 0 0 0 0 0 0 50000
gcc_mmss_qm_ahb_clk 0 0 0 0 0 0 50000
gcc_mmss_noc_cfg_ahb_clk 0 0 0 0 0 0 50000
gcc_lpass_trig_clk 0 0 0 0 0 0 50000
gcc_lpass_at_clk 1 1 0 0 0 0 50000
gcc_hmss_trig_clk 0 0 0 0 0 0 50000
gcc_hmss_dvm_bus_clk 1 1 0 0 0 0 50000
gcc_hmss_at_clk 0 0 0 0 0 0 50000
gcc_gpu_snoc_dvm_gfx_clk 0 0 0 0 0 0 50000
gcc_gpu_cfg_ahb_clk 0 0 0 0 0 0 50000
gcc_gpu_bimc_gfx_src_clk 0 0 0 0 0 0 50000
gcc_gpu_bimc_gfx_clk 0 0 0 0 0 0 50000
gcc_blsp2_sleep_clk 0 0 0 0 0 0 50000
gcc_blsp2_ahb_clk 3 3 0 0 0 0 50000
gcc_blsp1_sleep_clk 0 0 0 0 0 0 50000
gcc_blsp1_ahb_clk 0 0 0 0 0 0 50000
gcc_bimc_mss_q6_axi_clk 0 0 0 0 0 0 50000
gcc_bimc_hmss_axi_clk 0 0 0 0 0 0 50000
gcc_apss_qdss_tsctr_div8_clk 0 0 0 0 0 0 50000
gcc_apss_qdss_tsctr_div2_clk 0 0 0 0 0 0 50000
gcc_aggre1_noc_xo_clk 0 0 0 0 0 0 50000
sleep_clk 0 0 0 32764 0 0 50000
xo_board 1 1 0 19200000 0 0 50000
ln_bb_a_clk1 0 0 0 19200000 0 0 50000
ln_bb_clk1 0 0 0 19200000 0 0 50000
xo 1 1 0 19200000 0 0 50000
gcc_rx1_usb2_clkref_clk 0 0 0 19200000 0 0 50000
gcc_pcie_clkref_clk 0 0 0 19200000 0 0 50000
gcc_ufs_clkref_clk 0 0 0 19200000 0 0 50000
gcc_hdmi_clkref_clk 0 0 0 19200000 0 0 50000
gcc_usb3_clkref_clk 0 0 0 19200000 0 0 50000
usb3_phy_aux_clk_src 0 0 0 1200000 0 0 50000
gcc_usb3_phy_aux_clk 0 0 0 1200000 0 0 50000
usb30_mock_utmi_clk_src 0 0 0 19200000 0 0 50000
gcc_usb30_mock_utmi_clk 0 0 0 19200000 0 0 50000
tsif_ref_clk_src 0 0 0 19200000 0 0 50000
gcc_tsif_ref_clk 0 0 0 19200000 0 0 50000
sdcc4_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_sdcc4_apps_clk 0 0 0 19200000 0 0 50000
sdcc2_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_sdcc2_apps_clk 0 0 0 19200000 0 0 50000
pdm2_clk_src 0 0 0 19200000 0 0 50000
gcc_pdm2_clk 0 0 0 19200000 0 0 50000
pcie_aux_clk_src 0 0 0 19200000 0 0 50000
gcc_pcie_0_aux_clk 0 0 0 19200000 0 0 50000
gcc_pcie_phy_aux_clk 0 0 0 19200000 0 0 50000
hmss_rbcpr_clk_src 0 0 0 19200000 0 0 50000
gcc_hmss_rbcpr_clk 0 0 0 19200000 0 0 50000
hmss_ahb_clk_src 0 0 0 19200000 0 0 50000
gcc_hmss_ahb_clk 0 0 0 19200000 0 0 50000
gpll4 0 0 0 384000000 0 0 50000
gpll4_out_test 0 0 0 384000000 0 0 50000
gpll4_out_odd 0 0 0 384000000 0 0 50000
gpll4_out_main 0 0 0 384000000 0 0 50000
gpll4_out_even 0 0 0 384000000 0 0 50000
gpll3 0 0 0 921600000 0 0 50000
gpll3_out_test 0 0 0 921600000 0 0 50000
gpll3_out_odd 0 0 0 921600000 0 0 50000
gpll3_out_main 0 0 0 921600000 0 0 50000
gpll3_out_even 0 0 0 921600000 0 0 50000
gpll2 0 0 0 1286400000 0 0 50000
gpll2_out_test 0 0 0 1286400000 0 0 50000
gpll2_out_odd 0 0 0 1286400000 0 0 50000
gpll2_out_main 0 0 0 1286400000 0 0 50000
gpll2_out_even 0 0 0 1286400000 0 0 50000
gpll1 0 0 0 1056000000 0 0 50000
gpll1_out_test 0 0 0 1056000000 0 0 50000
gpll1_out_odd 0 0 0 1056000000 0 0 50000
gpll1_out_main 0 0 0 1056000000 0 0 50000
gpll1_out_even 0 0 0 1056000000 0 0 50000
gpll0 0 0 0 595200000 0 0 50000
gpll0_out_test 0 0 0 595200000 0 0 50000
gpll0_out_odd 0 0 0 595200000 0 0 50000
gpll0_out_main 0 0 0 595200000 0 0 50000
ufs_unipro_core_clk_src 0 0 0 148800000 0 0 50000
gcc_ufs_unipro_core_clk 0 0 0 148800000 0 0 50000
usb30_master_clk_src 0 0 0 119040000 0 0 50000
gcc_aggre1_usb3_axi_clk 0 0 0 119040000 0 0 50000
gcc_cfg_noc_usb3_axi_clk 0 0 0 119040000 0 0 50000
gcc_usb30_master_clk 0 0 0 119040000 0 0 50000
ufs_axi_clk_src 0 0 0 198400000 0 0 50000
gcc_aggre1_ufs_axi_clk 0 0 0 198400000 0 0 50000
gcc_ufs_axi_clk 0 0 0 198400000 0 0 50000
gpll0_out_even 0 0 0 595200000 0 0 50000
gp3_clk_src 0 0 0 19200000 0 0 50000
gcc_gp3_clk 0 0 0 19200000 0 0 50000
gp2_clk_src 0 0 0 19200000 0 0 50000
gcc_gp2_clk 0 0 0 19200000 0 0 50000
gp1_clk_src 0 0 0 19200000 0 0 50000
gcc_gp1_clk 0 0 0 19200000 0 0 50000
blsp2_uart3_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_uart3_apps_clk 0 0 0 19200000 0 0 50000
blsp2_uart2_apps_clk_src 1 1 0 1843200 0 0 50000
gcc_blsp2_uart2_apps_clk 3 3 0 1843200 0 0 50000
blsp2_uart1_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_uart1_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup6_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup6_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup6_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup6_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup5_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup5_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup5_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup5_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup4_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup4_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup4_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup4_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup3_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup3_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup3_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup3_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup2_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup2_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup2_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup2_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup1_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup1_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp2_qup1_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp2_qup1_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp1_uart3_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_uart3_apps_clk 0 0 0 19200000 0 0 50000
blsp1_uart2_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_uart2_apps_clk 0 0 0 19200000 0 0 50000
blsp1_uart1_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_uart1_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup6_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup6_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup6_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup6_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup5_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup5_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup5_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup5_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup4_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup4_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup4_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup4_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup3_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup3_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup3_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup3_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup2_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup2_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup2_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup2_i2c_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup1_spi_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup1_spi_apps_clk 0 0 0 19200000 0 0 50000
blsp1_qup1_i2c_apps_clk_src 0 0 0 19200000 0 0 50000
gcc_blsp1_qup1_i2c_apps_clk 0 0 0 19200000 0 0 50000
# grep ufs clk_summary
gcc_ufs_tx_symbol_0_clk 0 0 0 0 0 0 50000
gcc_ufs_rx_symbol_1_clk 0 0 0 0 0 0 50000
gcc_ufs_rx_symbol_0_clk 0 0 0 0 0 0 50000
gcc_ufs_phy_aux_clk 0 0 0 0 0 0 50000
gcc_ufs_ice_core_clk 0 0 0 0 0 0 50000
gcc_ufs_ahb_clk 0 0 0 0 0 0 50000
gcc_ufs_clkref_clk 0 0 0 19200000 0 0 50000
ufs_unipro_core_clk_src 0 0 0 148800000 0 0 50000
gcc_ufs_unipro_core_clk 0 0 0 148800000 0 0 50000
ufs_axi_clk_src 0 0 0 198400000 0 0 50000
gcc_aggre1_ufs_axi_clk 0 0 0 198400000 0 0 50000
gcc_ufs_axi_clk 0 0 0 198400000 0 0 50000
I find it surprising that many ufs-related clocks are unparented,
have no rate, and have never been enabled. But that's probably
a red-herring. As Bjorn mentioned, the bootloader probably leaves
all the UFS clocks in the correct state, so the problem must be
elsewhere... Will check the init sequence.
Just for completeness sake, here are the clock parents downstream:
CLOCK=gcc_ufs_ahb_clk PARENT=None
CLOCK=gcc_ufs_clkref_clk PARENT=None
CLOCK=gcc_ufs_rx_symbol_0_clk PARENT=None
CLOCK=gcc_ufs_rx_symbol_1_clk PARENT=None
CLOCK=gcc_ufs_tx_symbol_0_clk PARENT=None
CLOCK=gcc_aggre1_ufs_axi_clk PARENT=ufs_axi_clk_src
CLOCK=gcc_aggre1_ufs_axi_hw_ctl_clk PARENT=gcc_aggre1_ufs_axi_clk
CLOCK=gcc_ufs_axi_clk PARENT=ufs_axi_clk_src
CLOCK=gcc_ufs_axi_hw_ctl_clk PARENT=gcc_ufs_axi_clk
CLOCK=gcc_ufs_ice_core_clk PARENT=ufs_ice_core_clk_src
CLOCK=gcc_ufs_ice_core_hw_ctl_clk PARENT=gcc_ufs_ice_core_clk
CLOCK=gcc_ufs_phy_aux_clk PARENT=ufs_phy_aux_clk_src
CLOCK=gcc_ufs_phy_aux_hw_ctl_clk PARENT=gcc_ufs_phy_aux_clk
CLOCK=gcc_ufs_unipro_core_clk PARENT=ufs_unipro_core_clk_src
CLOCK=gcc_ufs_unipro_core_hw_ctl_clk PARENT=gcc_ufs_unipro_core_clk
CLOCK=ufs_axi_clk_src PARENT=gpll0_out_main
CLOCK=ufs_ice_core_clk_src PARENT=gpll0_out_main
CLOCK=ufs_phy_aux_clk_src PARENT=cxo_clk_src
CLOCK=ufs_unipro_core_clk_src PARENT=gpll0_out_main
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 14/25] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
From: Catalin Marinas @ 2018-12-06 16:17 UTC (permalink / raw)
To: James Morse
Cc: Tony Luck, Fan Wu, Xie XiuQi, Marc Zyngier, Will Deacon,
Rafael Wysocki, Christoffer Dall, Dongjiu Geng, linux-mm,
linux-acpi, Borislav Petkov, Naoya Horiguchi, kvmarm,
linux-arm-kernel, Len Brown
In-Reply-To: <20181203180613.228133-15-james.morse@arm.com>
On Mon, Dec 03, 2018 at 06:06:02PM +0000, James Morse wrote:
> To split up APEIs in_nmi() path, the caller needs to always be
> in_nmi(). Add a helper to do the work and claim the notification.
>
> When KVM or the arch code takes an exception that might be a RAS
> notification, it asks the APEI firmware-first code whether it wants
> to claim the exception. A future kernel-first mechanism may be queried
> afterwards, and claim the notification, otherwise we fall through
> to the existing default behaviour.
>
> The NOTIFY_SEA code was merged before considering multiple, possibly
> interacting, NMI-like notifications and the need to consider kernel
> first in the future. Make the 'claiming' behaviour explicit.
>
> Restructuring the APEI code to allow multiple NMI-like notifications
> means any notification that might interrupt interrupts-masked
> code must always be wrapped in nmi_enter()/nmi_exit(). This will
> allow APEI to use in_nmi() to use the right fixmap entries.
>
> Mask SError over this window to prevent an asynchronous RAS error
> arriving and tripping 'nmi_enter()'s BUG_ON(in_nmi()).
>
> Signed-off-by: James Morse <james.morse@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 13/25] KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
From: Catalin Marinas @ 2018-12-06 16:17 UTC (permalink / raw)
To: James Morse
Cc: Tony Luck, Fan Wu, Xie XiuQi, Marc Zyngier, Will Deacon,
Rafael Wysocki, Christoffer Dall, Dongjiu Geng, linux-mm,
linux-acpi, Borislav Petkov, Naoya Horiguchi, kvmarm,
linux-arm-kernel, Len Brown
In-Reply-To: <20181203180613.228133-14-james.morse@arm.com>
On Mon, Dec 03, 2018 at 06:06:01PM +0000, James Morse wrote:
> To split up APEIs in_nmi() path, the caller needs to always be
> in_nmi(). KVM shouldn't have to know about this, pull the RAS plumbing
> out into a header file.
>
> Currently guest synchronous external aborts are claimed as RAS
> notifications by handle_guest_sea(), which is hidden in the arch codes
> mm/fault.c. 32bit gets a dummy declaration in system_misc.h.
>
> There is going to be more of this in the future if/when the kernel
> supports the SError-based firmware-first notification mechanism and/or
> kernel-first notifications for both synchronous external abort and
> SError. Each of these will come with some Kconfig symbols and a
> handful of header files.
>
> Create a header file for all this.
>
> This patch gives handle_guest_sea() a 'kvm_' prefix, and moves the
> declarations to kvm_ras.h as preparation for a future patch that moves
> the ACPI-specific RAS code out of mm/fault.c.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
For the arm64 bits here:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: dmapool regression in next
From: Tony Battersby @ 2018-12-06 16:13 UTC (permalink / raw)
To: Robin Murphy, Krzysztof Kozlowski, tony, akpm
Cc: Stephen Rothwell, john.garry, linux, Matthew Wilcox, linux-kernel,
andy.shevchenko, linux-omap, hch, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <451215b8-548a-eff7-9e96-0ff5f8cbb614@arm.com>
On 12/6/18 10:51 AM, Robin Murphy wrote:
>> Here is the prototype:
>>
>> void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t dma);
>>
>> With the old code, the 'dma' value had to be correct for use with
>> pool_find_page(), or else you would get an error. If the 'vaddr' value
>> was incorrect, it would corrupt the dmapool freelist, but you wouldn't
>> get an error unless DMAPOOL_DEBUG was enabled.
>>
>> With my patch applied, 'vaddr' has to be correct for virt_to_page(). My
>> code also checks that 'dma' is consistent with 'vaddr' even if
>> DMAPOOL_DEBUG is disabled, since the check is fast and it will prevent
>> problems like this in the future.
> Unfortunately that logic has a fatal flaw - DMA pools are backed by
> dma_alloc_coherent(), and there is absolutely no guarantee that the
> memory dma_alloc_coherent() returns is backed by a struct page at all.
> Even if it is, there is still absolutely no guarantee that the vaddr
> value it returns is valid for virt_to_page() - on many systems it will
> be in vmalloc or some architecture-specific region of address space.
>
> The problem is not that these drivers are buggy (they're not - the arch
> code is returning a vmalloc()ed non-cacheable remap in the first place),
> it's that 26abe88e830d is fundamentally unworkable and needs reverting.
> Apparently the original patches managed not to catch my eye as something
> I needed to review, sorry about that :(
>
> Robin.
>
Thanks for the info; the inner workings of the vm system are a bit out
of my area of expertise. My first version of the patch series used a
different method that didn't rely on virt_to_page(); I will go back to
that version, clean it up, and resubmit when I have time.
Andrew, please revert all 9 patches. I will resubmit the set when I
have a workable solution.
Tony Battersby
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS
From: Robert Hancock @ 2018-12-06 16:10 UTC (permalink / raw)
To: Lucas Stach, Baruch Siach, Andrey Smirnov
Cc: A.s. Dong, Richard Zhu, linux-pci, linux-kernel, linux-imx,
bhelgaas, Leonard Crestez, cphealy, linux-arm-kernel,
Trent Piepho
In-Reply-To: <1544111431.3709.70.camel@pengutronix.de>
On 2018-12-06 9:50 a.m., Lucas Stach wrote:
> Am Donnerstag, den 06.12.2018, 09:45 -0600 schrieb Robert Hancock:
>> On 2018-12-06 2:10 a.m., Baruch Siach wrote:
>>> Hi Andrey,
>>>
>>> Adding Robert Hancock who reported[1] on a PCIe MSI issue with i.MX6.
>>>
>>> Andrey Smirnov writes:
>>>
>>>> Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
>>>> produces a system where built-in PCIE bridge (16c3:abcd) isn't bound
>>>> to pcieport driver. This, in turn, results in a PCIE bus that is
>>>> capable of enumerating attached PCIE device, but lacks functional
>>>> interrupt support.
>>>
>>> Robert, does that fix your issue?
>>
>> Unfortunately, no.. in fact the situation on my setup is even worse with
>> CONFIG_PCIEPORTBUS enabled: Not only does MSI still not function, but
>> now INTx interrupts are somehow broken as well - no interrupts are
>> received. The IRQ information shown in /proc/interrupts is correct, but
>> the count remains stubbornly at 0.
>
> That's expected. The port services will use an MSI IRQ when available
> and due to a design issue with the DWC PCIe it will not forward any
> legacy IRQs if any MSI is in use. If any of the PCIe devices in your
> system are unable to work with MSI IRQs, you must boot with "nomsi" on
> the kernel command line set.
That seems like an unfortunate design choice on their part.. well that
would probably argue against adding this as a hard dependency then, if
non-MSI-supporting PCIe devices can't work with default boot options
with that set.
I'm looking into testing with an NXP Smart Devices board and some PCIe
cards to see if I can verify whether MSI works on those or not, since we
currently don't have a way to independently verify that the MSI
implementation in our FPGA is working or whether another PCIe device
works with MSI (the FPGA is integrated on the system board).
--
Robert Hancock
Senior Software Developer
SED Systems
Email: hancock@sedsystems.ca
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: ftrace: Set FTRACE_SCHEDULABLE before ftrace_modify_all_code()
From: Will Deacon @ 2018-12-06 16:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: Anders Roxell, keescook, arnd, catalin.marinas, linux-kernel,
Ingo Molnar, linux-arm-kernel
In-Reply-To: <20181206105914.7a29efa9@vmware.local.home>
On Thu, Dec 06, 2018 at 10:59:14AM -0500, Steven Rostedt wrote:
> On Thu, 6 Dec 2018 13:20:07 +0000
> Will Deacon <will.deacon@arm.com> wrote:
>
> > On Wed, Dec 05, 2018 at 12:48:54PM -0500, Steven Rostedt wrote:
> > > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> > >
> > > It has been reported that ftrace_replace_code() which is called by
> > > ftrace_modify_all_code() can cause a soft lockup warning for an
> > > allmodconfig kernel. This is because all the debug options enabled
> > > causes the loop in ftrace_replace_code() (which loops over all the
> > > functions being enabled where there can be 10s of thousands), is too
> > > slow, and never schedules out.
> > >
> > > To solve this, setting FTRACE_SCHEDULABLE to the command passed into
> > > ftrace_replace_code() will make it call cond_resched() in the loop,
> > > which prevents the soft lockup warning from triggering.
> > >
> > > Link: http://lkml.kernel.org/r/20181204192903.8193-1-anders.roxell@linaro.org
> > >
> > > Reported-by: Anders Roxell <anders.roxell@linaro.org>
> > > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> > > ---
> > > arch/arm64/kernel/ftrace.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
> > > index 57e962290df3..9a8de0a79f97 100644
> > > --- a/arch/arm64/kernel/ftrace.c
> > > +++ b/arch/arm64/kernel/ftrace.c
> > > @@ -193,6 +193,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
> > >
> > > void arch_ftrace_update_code(int command)
> > > {
> > > + command |= FTRACE_SCHEDULABLE;
> > > ftrace_modify_all_code(command);
> > > }
> >
> > Bikeshed: I'd probably go for FTRACE_MAY_SLEEP, but I'm not going to die
> > on that hill so...
>
> I like bike sheds. Hmm, it's not too late to change this. Perhaps I
> will.
>
> >
> > Acked-by: Will Deacon <will.deacon@arm.com>
>
> Thanks!
>
> If I decide to change the name to MAY_SLEEP, I assume I can still keep
> your Acked-by.
Of course!
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: hugetlb: Register hugepages during arch init
From: Catalin Marinas @ 2018-12-06 16:04 UTC (permalink / raw)
To: Allen Pais
Cc: Anshuman Khandual, Will Deacon, linux-kernel, linux-arm-kernel,
Steve Capper
In-Reply-To: <1540256817-3327-1-git-send-email-allen.pais@oracle.com>
It seems that we somehow missed this patch. Cc'ing a few more people
that touched hugetlbpage.c.
Catalin
On Tue, Oct 23, 2018 at 06:36:57AM +0530, Allen Pais wrote:
> Add hstate for each supported hugepage size using arch initcall.
>
> * no hugepage parameters
>
> Without hugepage parameters, only a default hugepage size is
> available for dynamic allocation. It's different, for example, from
> x86_64 and sparc64 where all supported hugepage sizes are available.
>
> * only default_hugepagesz= is specified and set not to HPAGE_SIZE
>
> In spite of the fact that default_hugepagesz= is set to a valid
> hugepage size, it's treated as unsupported and reverted to
> HPAGE_SIZE. Such behaviour is also different from x86_64 and
> sparc64.
>
> Reviewed-by: Tom Saeger <tom.saeger@oracle.com>
> Signed-off-by: Dmitry Klochkov <dmitry.klochkov@oracle.com>
> Signed-off-by: Allen Pais <allen.pais@oracle.com>
> ---
> arch/arm64/mm/hugetlbpage.c | 33 ++++++++++++++++++++++-----------
> 1 file changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index f58ea50..28cbc22 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -429,6 +429,27 @@ void huge_ptep_clear_flush(struct vm_area_struct *vma,
> clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> }
>
> +static void __init add_huge_page_size(unsigned long size)
> +{
> + if (size_to_hstate(size))
> + return;
> +
> + hugetlb_add_hstate(ilog2(size) - PAGE_SHIFT);
> +}
> +
> +static int __init hugetlbpage_init(void)
> +{
> +#ifdef CONFIG_ARM64_4K_PAGES
> + add_huge_page_size(PUD_SIZE);
> +#endif
> + add_huge_page_size(PMD_SIZE * CONT_PMDS);
> + add_huge_page_size(PMD_SIZE);
> + add_huge_page_size(PAGE_SIZE * CONT_PTES);
> +
> + return 0;
> +}
> +arch_initcall(hugetlbpage_init);
> +
> static __init int setup_hugepagesz(char *opt)
> {
> unsigned long ps = memparse(opt, &opt);
> @@ -440,7 +461,7 @@ static __init int setup_hugepagesz(char *opt)
> case PMD_SIZE * CONT_PMDS:
> case PMD_SIZE:
> case PAGE_SIZE * CONT_PTES:
> - hugetlb_add_hstate(ilog2(ps) - PAGE_SHIFT);
> + add_huge_page_size(ps);
> return 1;
> }
>
> @@ -449,13 +470,3 @@ static __init int setup_hugepagesz(char *opt)
> return 0;
> }
> __setup("hugepagesz=", setup_hugepagesz);
> -
> -#ifdef CONFIG_ARM64_64K_PAGES
> -static __init int add_default_hugepagesz(void)
> -{
> - if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL)
> - hugetlb_add_hstate(CONT_PTE_SHIFT);
> - return 0;
> -}
> -arch_initcall(add_default_hugepagesz);
> -#endif
> --
> 1.8.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] pinctrl: sunxi: Account for per-bank GPIO regulators
From: Chen-Yu Tsai @ 2018-12-06 16:01 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-gpio, Linus Walleij, Mylène Josserand,
linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20181206154748.45iqfnlirm6blt4k@flea>
On Thu, Dec 6, 2018 at 11:47 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> On Thu, Dec 06, 2018 at 11:28:21PM +0800, Chen-Yu Tsai wrote:
> > On Thu, Dec 6, 2018 at 10:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > The main interogation I have currently is whether we should always try to
> > > get the regulator for the current branch, or if we should restrict it to
> > > the one available on the SoCs.
> >
> > Not sure what you mean here, but we should probably just list the actual
> > names.
>
> The A20 for example doesn't have a VCC-PB regulator, so do we want to
> try to grab it if we request a PB* pin, or should we just know that
> somehow and not do it?
AFAIK, pin banks that don't have a separate supply are powered collectively
by VCC-IO, as mentioned below in my previous reply.
> > For pre-A20 SoCs (A10/A10s/A13), they aren't even named VCC-Px. Instead
> > they are named after the primary function of the pin bank, such as
> > VCC-CARD, VCC-NAND, VCC-CSI0, VCC-CSI1.
>
> I'd really prefer to stick to vcc-pX, that's pretty obvious even for
> those older SoCs, and we can maintain some consistency that way.
IRRC Mark said that supply names should match design names, not what is
convenient. And then again there's the fallback for those that don't have
separate rails.
> > For pin banks that don't have per-bank power inputs, you should fall back
> > to VCC-IO, or VCC-RTC in the case of the PL pins.
> >
> > So here's the rub: On A33 and later SoCs that are paired with a PMIC, VCC-PL
> > or VCC-RTC is powered by the RTC regulator of the PMIC, which only gets
> > registered when the PMIC regulator driver is probed, which needs the RSB
> > controller, which needs the pin controller and the PL pins...
>
> I haven't seen any VCC-P* on the A33, do you have a reference?
The A33 has a VCC-PD. This is not listed in the datasheet, but is shown in
schematics. Other pins would be powered by VCC-IO, with the exception of PL,
which would be power by VCC-RTC. The last bit is just a guess. We should
probably ask Allwinner, or try to do some tests.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v11 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver
From: Ganapatrao Kulkarni @ 2018-12-06 16:01 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Nair, Jayachandran, Randy Dunlap, linux-doc,
suzuki.poulose, LKML, Robert Richter, Vadim.Lomovtsev,
Ganapatrao Kulkarni, Jan.Glauber, linux-arm-kernel
In-Reply-To: <20181206123420.GA26473@arm.com>
On Thu, Dec 6, 2018 at 6:04 PM Will Deacon <will.deacon@arm.com> wrote:
>
> Hi Ganapat,
>
> On Thu, Dec 06, 2018 at 11:51:24AM +0000, Kulkarni, Ganapatrao wrote:
> > This patchset adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
> > The SoC has PMU support in L3 cache controller (L3C) and in the
> > DDR4 Memory Controller (DMC).
> >
> >
> > v11:
> > Updated Patch 2 with minor comments.
>
> Thanks. I've pushed this out on my perf/updates branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=perf/updates
>
> but note that I did make some spelling and formatting changes to the
> Documentation patch, as well as removal of the event descriptions (they
> should be part of the perf tool, as is done for the other system PMUs).
Thanks Will.
>
> Will
Thanks,
Ganapat
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/5] arm64/alternative_cb: add nr_alts parameter to callback handlers
From: Ard Biesheuvel @ 2018-12-06 15:57 UTC (permalink / raw)
To: linux-kernel
Cc: Ard Biesheuvel, Marc Zyngier, Catalin Marinas, Suzuki Poulose,
Will Deacon, Robin Murphy, Dave Martin, linux-arm-kernel
In-Reply-To: <20181206155739.20229-1-ard.biesheuvel@linaro.org>
Callback handlers for alternative patching will shortly be able to
access a set of alternative instructions provided at assembly time.
So update the callback handler prototypes so we can pass this number.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/alternative.h | 4 ++--
arch/arm64/include/asm/kvm_mmu.h | 4 ++--
arch/arm64/kernel/alternative.c | 11 +++++++----
arch/arm64/kernel/cpu_errata.c | 10 ++++------
arch/arm64/kvm/va_layout.c | 8 ++++----
5 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index 77da798e888b..987c1514183a 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -29,8 +29,8 @@ struct alt_instr_cb {
__le32 insn[]; /* sequence of alternative instructions */
};
-typedef void (*alternative_cb_t)(struct alt_instr *alt,
- __le32 *origptr, __le32 *updptr, int nr_inst);
+typedef void (*alternative_cb_t)(struct alt_instr *alt, __le32 *origptr,
+ __le32 *updptr, int nr_inst, int nr_alts);
void __init apply_alternatives_all(void);
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 658657367f2f..5e32e314b9f0 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -100,8 +100,8 @@ alternative_cb_end
#include <asm/mmu_context.h>
#include <asm/pgtable.h>
-void kvm_update_va_mask(struct alt_instr *alt,
- __le32 *origptr, __le32 *updptr, int nr_inst);
+void kvm_update_va_mask(struct alt_instr *alt, __le32 *origptr,
+ __le32 *updptr, int nr_insti, int nr_alts);
static inline unsigned long __kern_hyp_va(unsigned long v)
{
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index a49930843784..f55afa0bbaa4 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -107,8 +107,8 @@ static u32 get_alt_insn(struct alt_instr *alt, __le32 *insnptr, __le32 *altinsnp
return insn;
}
-static void patch_alternative(struct alt_instr *alt,
- __le32 *origptr, __le32 *updptr, int nr_inst)
+static void patch_alternative(struct alt_instr *alt, __le32 *origptr,
+ __le32 *updptr, int nr_inst, int nr_alts)
{
__le32 *replptr;
int i;
@@ -154,7 +154,7 @@ static void __apply_alternatives(void *alt_region, bool is_module)
struct alt_instr_cb *alt_cb_insn;
for (alt = region->begin; alt < region->end; alt++) {
- int nr_inst;
+ int nr_inst, nr_alts;
/* Use ARM64_CB_PATCH as an unconditional patch */
if (alt->cpufeature < ARM64_CB_PATCH &&
@@ -174,12 +174,15 @@ static void __apply_alternatives(void *alt_region, bool is_module)
if (alt->cpufeature < ARM64_CB_PATCH) {
alt_cb = patch_alternative;
+ nr_alts = alt->alt_len / AARCH64_INSN_SIZE;
} else {
alt_cb_insn = ALT_REPL_PTR(alt);
alt_cb = offset_to_ptr(&alt_cb_insn->cb_offset);
+ nr_alts = (alt->alt_len - sizeof(*alt_cb_insn)) / AARCH64_INSN_SIZE;
+
}
- alt_cb(alt, origptr, updptr, nr_inst);
+ alt_cb(alt, origptr, updptr, nr_inst, nr_alts);
if (!is_module) {
clean_dcache_range_nopatch((u64)origptr,
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 6ad715d67df8..c5489b4612c5 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -305,9 +305,8 @@ static int __init ssbd_cfg(char *buf)
}
early_param("ssbd", ssbd_cfg);
-void __init arm64_update_smccc_conduit(struct alt_instr *alt,
- __le32 *origptr, __le32 *updptr,
- int nr_inst)
+void __init arm64_update_smccc_conduit(struct alt_instr *alt, __le32 *origptr,
+ __le32 *updptr, int nr_inst, int nr_alts)
{
u32 insn;
@@ -327,9 +326,8 @@ void __init arm64_update_smccc_conduit(struct alt_instr *alt,
*updptr = cpu_to_le32(insn);
}
-void __init arm64_enable_wa2_handling(struct alt_instr *alt,
- __le32 *origptr, __le32 *updptr,
- int nr_inst)
+void __init arm64_enable_wa2_handling(struct alt_instr *alt, __le32 *origptr,
+ __le32 *updptr, int nr_inst, int nr_alts)
{
BUG_ON(nr_inst != 1);
/*
diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c
index c712a7376bc1..db7ba73e306a 100644
--- a/arch/arm64/kvm/va_layout.c
+++ b/arch/arm64/kvm/va_layout.c
@@ -114,8 +114,8 @@ static u32 compute_instruction(int n, u32 rd, u32 rn)
return insn;
}
-void __init kvm_update_va_mask(struct alt_instr *alt,
- __le32 *origptr, __le32 *updptr, int nr_inst)
+void __init kvm_update_va_mask(struct alt_instr *alt, __le32 *origptr,
+ __le32 *updptr, int nr_inst, int nr_alts)
{
int i;
@@ -154,8 +154,8 @@ void __init kvm_update_va_mask(struct alt_instr *alt,
void *__kvm_bp_vect_base;
int __kvm_harden_el2_vector_slot;
-void kvm_patch_vector_branch(struct alt_instr *alt,
- __le32 *origptr, __le32 *updptr, int nr_inst)
+void kvm_patch_vector_branch(struct alt_instr *alt, __le32 *origptr,
+ __le32 *updptr, int nr_inst, int nr_alts)
{
u64 addr;
u32 insn;
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/5] arm64/alternative_cb: move callback reference into replacements section
From: Ard Biesheuvel @ 2018-12-06 15:57 UTC (permalink / raw)
To: linux-kernel
Cc: Ard Biesheuvel, Marc Zyngier, Catalin Marinas, Suzuki Poulose,
Will Deacon, Robin Murphy, Dave Martin, linux-arm-kernel
In-Reply-To: <20181206155739.20229-1-ard.biesheuvel@linaro.org>
In preparation of permitting callback type alternatives patching
routines to use any number of alternative instructions, move the
relative reference to the callback routine out of the primary
'struct alt_instr' data structure, where we are currently overloading
the 'alt_offset' member depending on the feature id. Instead, put
a relative reference to the callback at the start of the alternative
sequence.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/alternative.h | 39 +++++++++-----------
arch/arm64/kernel/alternative.c | 11 ++++--
2 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index 4b650ec1d7dd..77da798e888b 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -24,6 +24,11 @@ struct alt_instr {
u8 alt_len; /* size of new instruction(s), <= orig_len */
};
+struct alt_instr_cb {
+ s32 cb_offset; /* offset to callback handler */
+ __le32 insn[]; /* sequence of alternative instructions */
+};
+
typedef void (*alternative_cb_t)(struct alt_instr *alt,
__le32 *origptr, __le32 *updptr, int nr_inst);
@@ -35,13 +40,9 @@ void apply_alternatives_module(void *start, size_t length);
static inline void apply_alternatives_module(void *start, size_t length) { }
#endif
-#define ALTINSTR_ENTRY(feature,cb) \
+#define ALTINSTR_ENTRY(feature) \
" .word 661b - .\n" /* label */ \
- " .if " __stringify(cb) " == 0\n" \
" .word 663f - .\n" /* new instruction */ \
- " .else\n" \
- " .word " __stringify(cb) "- .\n" /* callback */ \
- " .endif\n" \
" .hword " __stringify(feature) "\n" /* feature bit */ \
" .byte 662b-661b\n" /* source len */ \
" .byte 664f-663f\n" /* replacement len */
@@ -59,36 +60,29 @@ static inline void apply_alternatives_module(void *start, size_t length) { }
* but most assemblers die if insn1 or insn2 have a .inst. This should
* be fixed in a binutils release posterior to 2.25.51.0.2 (anything
* containing commit 4e4d08cf7399b606 or c1baaddf8861).
- *
- * Alternatives with callbacks do not generate replacement instructions.
*/
-#define __ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg_enabled, cb) \
- ".if "__stringify(cfg_enabled)" == 1\n" \
+#define __ALTERNATIVE_CFG(oldinstr, newinstr, feature) \
"661:\n\t" \
oldinstr "\n" \
"662:\n" \
".pushsection .altinstructions,\"a\"\n" \
- ALTINSTR_ENTRY(feature,cb) \
+ ALTINSTR_ENTRY(feature) \
".popsection\n" \
- " .if " __stringify(cb) " == 0\n" \
".pushsection .altinstr_replacement, \"a\"\n" \
"663:\n\t" \
newinstr "\n" \
"664:\n\t" \
- ".popsection\n\t" \
+ ".popsection\n\t"
+
+#define _ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg, ...) \
+ ".if "__stringify(IS_ENABLED(cfg))" == 1\n" \
+ __ALTERNATIVE_CFG(oldinstr, newinstr, feature) \
".org . - (664b-663b) + (662b-661b)\n\t" \
".org . - (662b-661b) + (664b-663b)\n" \
- ".else\n\t" \
- "663:\n\t" \
- "664:\n\t" \
- ".endif\n" \
".endif\n"
-#define _ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg, ...) \
- __ALTERNATIVE_CFG(oldinstr, newinstr, feature, IS_ENABLED(cfg), 0)
-
#define ALTERNATIVE_CB(oldinstr, cb) \
- __ALTERNATIVE_CFG(oldinstr, "NOT_AN_INSTRUCTION", ARM64_CB_PATCH, 1, cb)
+ __ALTERNATIVE_CFG(oldinstr, ".word " __stringify(cb) " - .\n", ARM64_CB_PATCH)
#else
#include <asm/assembler.h>
@@ -158,8 +152,11 @@ static inline void apply_alternatives_module(void *start, size_t length) { }
.macro alternative_cb cb
.set .Lasm_alt_mode, 0
.pushsection .altinstructions, "a"
- altinstruction_entry 661f, \cb, ARM64_CB_PATCH, 662f-661f, 0
+ altinstruction_entry 661f, 663f, ARM64_CB_PATCH, 662f-661f, 664f-663f
.popsection
+ .pushsection .altinstr_replacement, "ax"
+663: .word \cb - .
+664: .popsection
661:
.endm
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index b5d603992d40..a49930843784 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -151,6 +151,7 @@ static void __apply_alternatives(void *alt_region, bool is_module)
struct alt_region *region = alt_region;
__le32 *origptr, *updptr;
alternative_cb_t alt_cb;
+ struct alt_instr_cb *alt_cb_insn;
for (alt = region->begin; alt < region->end; alt++) {
int nr_inst;
@@ -161,7 +162,7 @@ static void __apply_alternatives(void *alt_region, bool is_module)
continue;
if (alt->cpufeature == ARM64_CB_PATCH)
- BUG_ON(alt->alt_len != 0);
+ BUG_ON(alt->alt_len < sizeof(*alt_cb_insn));
else
BUG_ON(alt->alt_len != alt->orig_len);
@@ -171,10 +172,12 @@ static void __apply_alternatives(void *alt_region, bool is_module)
updptr = is_module ? origptr : lm_alias(origptr);
nr_inst = alt->orig_len / AARCH64_INSN_SIZE;
- if (alt->cpufeature < ARM64_CB_PATCH)
+ if (alt->cpufeature < ARM64_CB_PATCH) {
alt_cb = patch_alternative;
- else
- alt_cb = ALT_REPL_PTR(alt);
+ } else {
+ alt_cb_insn = ALT_REPL_PTR(alt);
+ alt_cb = offset_to_ptr(&alt_cb_insn->cb_offset);
+ }
alt_cb(alt, origptr, updptr, nr_inst);
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/5] arm64/alternative_cb: add support for alternative sequences
From: Ard Biesheuvel @ 2018-12-06 15:57 UTC (permalink / raw)
To: linux-kernel
Cc: Ard Biesheuvel, Marc Zyngier, Catalin Marinas, Suzuki Poulose,
Will Deacon, Robin Murphy, Dave Martin, linux-arm-kernel
In-Reply-To: <20181206155739.20229-1-ard.biesheuvel@linaro.org>
Permit callback type alternatives to carry a sequence of alternative
instructions, and leave it up to the callback handler to decide how
to use them.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/alternative.h | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index 987c1514183a..6b7726ee6b0a 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -156,7 +156,7 @@ static inline void apply_alternatives_module(void *start, size_t length) { }
.popsection
.pushsection .altinstr_replacement, "ax"
663: .word \cb - .
-664: .popsection
+ .popsection
661:
.endm
@@ -185,10 +185,21 @@ static inline void apply_alternatives_module(void *start, size_t length) { }
.org . - (662b-661b) + (664b-663b)
.endm
+.macro alternative_cb_alt
+ .set .Lasm_alt_mode, 1
+ .pushsection .altinstr_replacement, "ax"
+ .org 663b + AARCH64_INSN_SIZE
+.endm
+
/*
* Callback-based alternative epilogue
*/
.macro alternative_cb_end
+ .if .Lasm_alt_mode==0
+ .pushsection .altinstr_replacement, "ax"
+ .org 663b + AARCH64_INSN_SIZE
+ .endif
+664: .popsection
662:
.endm
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/5] arm64/mm: use string comparisons in dcache_by_line_op
From: Ard Biesheuvel @ 2018-12-06 15:57 UTC (permalink / raw)
To: linux-kernel
Cc: Ard Biesheuvel, Marc Zyngier, Catalin Marinas, Suzuki Poulose,
Will Deacon, Robin Murphy, Dave Martin, linux-arm-kernel
In-Reply-To: <20181206155739.20229-1-ard.biesheuvel@linaro.org>
The GAS directives that are currently being used in dcache_by_line_op
rely on assembler behavior that is not documented, and probably not
guaranteed to produce the correct behavior going forward.
Currently, we end up with some undefined symbols in cache.o:
$ nm arch/arm64/mm/cache.o
...
U civac
...
U cvac
U cvap
U cvau
This is due to the fact that the comparisons used to select the
operation type in the dcache_by_line_op macro are comparing symbols
not strings, and even though it seems that GAS is doing the right
thing here (undefined symbols by the same name are equal to each
other), it seems unwise to rely on this.
So let's switch to conditional directives that are documented as
operating on strings. Since these cannot be combined like ordinary
arithmetic expressions, invert the comparison logic.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/assembler.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 09c5a5452f60..df3043e76e6a 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -383,21 +383,23 @@ alternative_endif
sub \tmp2, \tmp1, #1
bic \kaddr, \kaddr, \tmp2
9998:
- .if (\op == cvau || \op == cvac)
+ .ifnc \op, civac
+ .ifnc \op, cvap
alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
dc \op, \kaddr
alternative_else
dc civac, \kaddr
alternative_endif
- .elseif (\op == cvap)
+ .else
alternative_cb arm64_handle_dc_cvap
dc civac, \kaddr
alternative_cb_alt
sys 3, c7, c12, 1, \kaddr // dc cvap
dc cvac, \kaddr
alternative_cb_end
+ .endif
.else
- dc \op, \kaddr
+ dc civac, \kaddr
.endif
add \kaddr, \kaddr, \tmp1
cmp \kaddr, \size
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/5] arm64/assembler: use callback to 3-way alt-patch DC CVAP instructions
From: Ard Biesheuvel @ 2018-12-06 15:57 UTC (permalink / raw)
To: linux-kernel
Cc: Ard Biesheuvel, Marc Zyngier, Catalin Marinas, Suzuki Poulose,
Will Deacon, Robin Murphy, Dave Martin, linux-arm-kernel
In-Reply-To: <20181206155739.20229-1-ard.biesheuvel@linaro.org>
Use the enhanced alternative_cb implementation to reimplement the code
patching logic for DC CVAP instructions so that we don't fall back to
DV CVAC instructions on systems that require those to be upgraded to
DC CIVAC to work around silicon errata. At the same time, we don't want
to use DV CIVAC needlessly, since doing so may adversely affect
performance.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/assembler.h | 9 +++++----
arch/arm64/kernel/cpu_errata.c | 14 ++++++++++++++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 6142402c2eb4..09c5a5452f60 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -390,11 +390,12 @@ alternative_else
dc civac, \kaddr
alternative_endif
.elseif (\op == cvap)
-alternative_if ARM64_HAS_DCPOP
- sys 3, c7, c12, 1, \kaddr // dc cvap
-alternative_else
+alternative_cb arm64_handle_dc_cvap
+ dc civac, \kaddr
+alternative_cb_alt
+ sys 3, c7, c12, 1, \kaddr // dc cvap
dc cvac, \kaddr
-alternative_endif
+alternative_cb_end
.else
dc \op, \kaddr
.endif
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index c5489b4612c5..a63e362da307 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -755,3 +755,17 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
{
}
};
+
+asmlinkage void __init arm64_handle_dc_cvap(struct alt_instr *alt,
+ __le32 *origptr, __le32 *updptr,
+ int nr_inst, int nr_alts)
+{
+ struct alt_instr_cb *alt_insn = offset_to_ptr(&alt->alt_offset);
+
+ BUG_ON(nr_inst != 1 || nr_alts != 2);
+
+ if (cpus_have_cap(ARM64_HAS_DCPOP))
+ updptr[0] = alt_insn->insn[0];
+ else if (!cpus_have_cap(ARM64_WORKAROUND_CLEAN_CACHE))
+ updptr[0] = alt_insn->insn[1];
+}
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/5] arm64: assorted fixes for dcache_by_line_op
From: Ard Biesheuvel @ 2018-12-06 15:57 UTC (permalink / raw)
To: linux-kernel
Cc: Ard Biesheuvel, Marc Zyngier, Catalin Marinas, Suzuki Poulose,
Will Deacon, Robin Murphy, Dave Martin, linux-arm-kernel
This fixes two issues in dcache_by_line_op: patch #4 fixes the logic
that is applied when patching DC CVAP instructions, and patch #5 gets
rid of some unintended undefined symbols resulting from incorrect use
of conditional GAS directives.
Patches #1 to #3 are groundwork for #4.
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: Dave Martin <Dave.Martin@arm.com>
Ard Biesheuvel (5):
arm64/alternative_cb: move callback reference into replacements
section
arm64/alternative_cb: add nr_alts parameter to callback handlers
arm64/alternative_cb: add support for alternative sequences
arm64/assembler: use callback to 3-way alt-patch DC CVAP instructions
arm64/mm: use string comparisons in dcache_by_line_op
arch/arm64/include/asm/alternative.h | 54 +++++++++++---------
arch/arm64/include/asm/assembler.h | 17 +++---
arch/arm64/include/asm/kvm_mmu.h | 4 +-
arch/arm64/kernel/alternative.c | 22 +++++---
arch/arm64/kernel/cpu_errata.c | 24 ++++++---
arch/arm64/kvm/va_layout.c | 8 +--
6 files changed, 79 insertions(+), 50 deletions(-)
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: ftrace: Set FTRACE_SCHEDULABLE before ftrace_modify_all_code()
From: Steven Rostedt @ 2018-12-06 15:59 UTC (permalink / raw)
To: Will Deacon
Cc: Anders Roxell, keescook, arnd, catalin.marinas, linux-kernel,
Ingo Molnar, linux-arm-kernel
In-Reply-To: <20181206132007.GB27744@arm.com>
On Thu, 6 Dec 2018 13:20:07 +0000
Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Dec 05, 2018 at 12:48:54PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> >
> > It has been reported that ftrace_replace_code() which is called by
> > ftrace_modify_all_code() can cause a soft lockup warning for an
> > allmodconfig kernel. This is because all the debug options enabled
> > causes the loop in ftrace_replace_code() (which loops over all the
> > functions being enabled where there can be 10s of thousands), is too
> > slow, and never schedules out.
> >
> > To solve this, setting FTRACE_SCHEDULABLE to the command passed into
> > ftrace_replace_code() will make it call cond_resched() in the loop,
> > which prevents the soft lockup warning from triggering.
> >
> > Link: http://lkml.kernel.org/r/20181204192903.8193-1-anders.roxell@linaro.org
> >
> > Reported-by: Anders Roxell <anders.roxell@linaro.org>
> > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> > ---
> > arch/arm64/kernel/ftrace.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
> > index 57e962290df3..9a8de0a79f97 100644
> > --- a/arch/arm64/kernel/ftrace.c
> > +++ b/arch/arm64/kernel/ftrace.c
> > @@ -193,6 +193,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
> >
> > void arch_ftrace_update_code(int command)
> > {
> > + command |= FTRACE_SCHEDULABLE;
> > ftrace_modify_all_code(command);
> > }
>
> Bikeshed: I'd probably go for FTRACE_MAY_SLEEP, but I'm not going to die
> on that hill so...
I like bike sheds. Hmm, it's not too late to change this. Perhaps I
will.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Thanks!
If I decide to change the name to MAY_SLEEP, I assume I can still keep
your Acked-by.
-- Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Krzysztof Kozlowski @ 2018-12-06 15:58 UTC (permalink / raw)
To: linux
Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
Morten.Rasmussen, Qais.Yousef, dietmar.eggemann, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20181206153128.GW30658@n2100.armlinux.org.uk>
On Thu, 6 Dec 2018 at 16:31, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
>
> On Thu, Dec 06, 2018 at 04:03:27PM +0100, Krzysztof Kozlowski wrote:
> > On Thu, 6 Dec 2018 at 15:37, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Thu, Dec 06, 2018 at 03:30:22PM +0100, Krzysztof Kozlowski wrote:
> > > > On Thu, 6 Dec 2018 at 15:07, Russell King - ARM Linux
> > > > > That basically means that the dcache_clean_area method for CPU1
> > > > > differs from the dcache_clean_area method for CPU0. If all your
> > > > > CPUs are identical, that definitely should not be happening.
> > > > >
> > > > > Hmm. Interestingly, OMAP4430 passes hotplug tests just fine.
> > > > >
> > > > > Please try this patch.
> > > >
> > > > This fixes both hotplug and suspend to RAM. I was trying to narrow why
> > > > the pointers to all processor functions differ. During first boot they
> > > > were OK but it seems they were changed just before suspend.
> > >
> > > Thanks for testing. I think this is probably a better patch which
> > > should end up with the same result.
> > >
> > > I suspect no one else has noticed because most people have big.Little
> > > support disabled - that'd explain why it doesn't show up on OMAP4.
> > >
> > > diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
> > > index 81d0efb055c6..44f9776139a8 100644
> > > --- a/arch/arm/mm/proc-macros.S
> > > +++ b/arch/arm/mm/proc-macros.S
> > > @@ -274,6 +274,13 @@
> > > .endm
> > >
> > > .macro define_processor_functions name:req, dabort:req, pabort:req, nommu=0, suspend=0, bugs=0
> > > +/*
> > > + * If we are building for big.Little with branch predictor hardening,
> > > + * we need the processor function tables to remain available after boot.
> > > + */
> > > +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> > > + .rodata
> > > +#endif
> > > .type \name\()_processor_functions, #object
> > > .align 2
> > > ENTRY(\name\()_processor_functions)
> > > @@ -309,6 +316,9 @@ ENTRY(\name\()_processor_functions)
> > > .endif
> > >
> > > .size \name\()_processor_functions, . - \name\()_processor_functions
> > > +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> > > + .previous
> > > +#endif
> > > .endm
> > >
> > > .macro define_cache_functions name:req
> >
> > Does not compile:
> > ../arch/arm/mm/proc-v7.S: Assembler messages:
> > ../arch/arm/mm/proc-v7.S:560: Error: unknown pseudo-op: `.rodata'
> > ../arch/arm/mm/proc-v7.S:575: Error: unknown pseudo-op: `.rodata'
> > ../arch/arm/mm/proc-v7.S:596: Error: unknown pseudo-op: `.rodata'
> > ../arch/arm/mm/proc-v7.S:611: Error: unknown pseudo-op: `.rodata'
> > ../arch/arm/mm/proc-v7.S:629: Error: unknown pseudo-op: `.rodata'
>
> It should be .section ".rodata", sorry.
Tested hotplug and suspend on Odroid U3 (Exynos4412), hotplug on
Odroid XU3 and HC1 (Exynos5422).
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
On Odroid U3 and HC1 the cpuhotplug_04 from Linaro's PM-QA fails:
cpuhotplug_04.0/cpu1: checking affinity is set... Err
v4.19 also fails here.
On HC1 the board hang once during cpuhotplug_05 test
(https://wiki.linaro.org/WorkingGroups/PowerManagement/Resources/TestSuite/PmQaSpecification#cpuhotplug_05).
Both errors above seems to be unrelated to your fixup. If needed I
could do some more testing during the weekend but in general looks
fine for me.
Thanks!
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [for-next][PATCH 05/30] arm64: function_graph: Remove use of FTRACE_NOTRACE_DEPTH
From: Steven Rostedt @ 2018-12-06 15:55 UTC (permalink / raw)
To: Will Deacon
Cc: Tom Zanussi, Catalin Marinas, linux-kernel, Ravi Bangoria,
Masami Hiramatsu, Joel Fernandes (Google), Namhyung Kim,
Andrew Morton, Ingo Molnar, linux-arm-kernel
In-Reply-To: <20181206154931.GA4327@arm.com>
On Thu, 6 Dec 2018 15:49:32 +0000
Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Dec 05, 2018 at 06:47:54PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> >
> > Functions in the set_graph_notrace no longer subtract FTRACE_NOTRACE_DEPTH
> > from curr_ret_stack, as that is now implemented via the trace_recursion
> > flags. Access to curr_ret_stack no longer needs to worry about checking for
> > this. curr_ret_stack is still initialized to -1, when there's not a shadow
> > stack allocated.
> >
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> > ---
> > arch/arm64/kernel/stacktrace.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> > index 4989f7ea1e59..7723dadf25be 100644
> > --- a/arch/arm64/kernel/stacktrace.c
> > +++ b/arch/arm64/kernel/stacktrace.c
> > @@ -61,9 +61,6 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
> > (frame->pc == (unsigned long)return_to_handler)) {
> > if (WARN_ON_ONCE(frame->graph == -1))
> > return -EINVAL;
> > - if (frame->graph < -1)
> > - frame->graph += FTRACE_NOTRACE_DEPTH;
> > -
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
Thanks Will!
-- Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: clearfog-gt-8k: describe mini-PCIe CON2 USB
From: Gregory CLEMENT @ 2018-12-06 15:55 UTC (permalink / raw)
To: Baruch Siach
Cc: Russell King, Andrew Lunn, Jason Cooper, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <634478cc2f11ea3ee3b89393ae6d82f39d3c8531.1544095149.git.baruch@tkos.co.il>
Hi Baruch,
On jeu., déc. 06 2018, Baruch Siach <baruch@tkos.co.il> wrote:
> Enable the USB3 peripheral that is wired to CON2 on the Clearfog GT-8K
> board.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
> index dfb26661a88e..5b4a9609e31f 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
> @@ -282,6 +282,10 @@
> vqmmc-supply = <&v_3_3>;
> };
>
> +&cp0_usb3_1 {
Don't you have any phy for this USB3 port?
Gregory
> + status = "okay";
> +};
> +
> &cp1_pinctrl {
> /*
> * MPP Bus:
> --
> 2.19.2
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Marek Szyprowski @ 2018-12-06 15:54 UTC (permalink / raw)
To: Russell King - ARM Linux, Krzysztof Kozlowski
Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
Morten.Rasmussen, dietmar.eggemann, linux-arm-kernel, Qais.Yousef
In-Reply-To: <20181206153128.GW30658@n2100.armlinux.org.uk>
On 2018-12-06 16:31, Russell King - ARM Linux wrote:
> On Thu, Dec 06, 2018 at 04:03:27PM +0100, Krzysztof Kozlowski wrote:
>> On Thu, 6 Dec 2018 at 15:37, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>>> On Thu, Dec 06, 2018 at 03:30:22PM +0100, Krzysztof Kozlowski wrote:
>>>> On Thu, 6 Dec 2018 at 15:07, Russell King - ARM Linux
>>>>> That basically means that the dcache_clean_area method for CPU1
>>>>> differs from the dcache_clean_area method for CPU0. If all your
>>>>> CPUs are identical, that definitely should not be happening.
>>>>>
>>>>> Hmm. Interestingly, OMAP4430 passes hotplug tests just fine.
>>>>>
>>>>> Please try this patch.
>>>> This fixes both hotplug and suspend to RAM. I was trying to narrow why
>>>> the pointers to all processor functions differ. During first boot they
>>>> were OK but it seems they were changed just before suspend.
>>> Thanks for testing. I think this is probably a better patch which
>>> should end up with the same result.
>>>
>>> I suspect no one else has noticed because most people have big.Little
>>> support disabled - that'd explain why it doesn't show up on OMAP4.
>>>
>>> diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
>>> index 81d0efb055c6..44f9776139a8 100644
>>> --- a/arch/arm/mm/proc-macros.S
>>> +++ b/arch/arm/mm/proc-macros.S
>>> @@ -274,6 +274,13 @@
>>> .endm
>>>
>>> .macro define_processor_functions name:req, dabort:req, pabort:req, nommu=0, suspend=0, bugs=0
>>> +/*
>>> + * If we are building for big.Little with branch predictor hardening,
>>> + * we need the processor function tables to remain available after boot.
>>> + */
>>> +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
>>> + .rodata
>>> +#endif
>>> .type \name\()_processor_functions, #object
>>> .align 2
>>> ENTRY(\name\()_processor_functions)
>>> @@ -309,6 +316,9 @@ ENTRY(\name\()_processor_functions)
>>> .endif
>>>
>>> .size \name\()_processor_functions, . - \name\()_processor_functions
>>> +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
>>> + .previous
>>> +#endif
>>> .endm
>>>
>>> .macro define_cache_functions name:req
>> Does not compile:
>> ../arch/arm/mm/proc-v7.S: Assembler messages:
>> ../arch/arm/mm/proc-v7.S:560: Error: unknown pseudo-op: `.rodata'
>> ../arch/arm/mm/proc-v7.S:575: Error: unknown pseudo-op: `.rodata'
>> ../arch/arm/mm/proc-v7.S:596: Error: unknown pseudo-op: `.rodata'
>> ../arch/arm/mm/proc-v7.S:611: Error: unknown pseudo-op: `.rodata'
>> ../arch/arm/mm/proc-v7.S:629: Error: unknown pseudo-op: `.rodata'
> It should be .section ".rodata", sorry.
With the above change, the issue is fixed, both for hotplug and s2r.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v16 06/16] lib: fdt: add a helper function for handling memory range property
From: Will Deacon @ 2018-12-06 15:54 UTC (permalink / raw)
To: Rob Herring
Cc: prudo, Herbert Xu, Baoquan He, Ard Biesheuvel, Catalin Marinas,
bhsharma, Frank Rowand, Heiko Carstens,
linux-kernel@vger.kernel.org, David Howells, AKASHI, Takahiro,
devicetree, Arnd Bergmann,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, kexec,
Martin Schwidefsky, James Morse, dyoung, David Miller,
Vivek Goyal
In-Reply-To: <CAL_JsqL4_Z5pVfoB3opjL7eTzZvhBJW7_aQS443quAAR0gGH1w@mail.gmail.com>
Hi Rob,
Thanks for reviewing this.
On Thu, Dec 06, 2018 at 08:47:04AM -0600, Rob Herring wrote:
> On Wed, Nov 14, 2018 at 11:52 PM AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> >
> > Added function, fdt_setprop_reg(), will be used later to handle
> > kexec-specific property in arm64's kexec_file implementation.
> > It will possibly be merged into libfdt in the future.
>
> You generally can't modify libfdt files. Any changes will be blown
> away with the next dtc sync (there's one in -next now). Though here
> you are creating a new location with fdt code. lib/ is just a shim to
> the actual libfdt code. Don't put any implementation there. You can
> add this to drivers/of/fdt_address.c for the short term, but it still
> needs to go upstream.
>
> Otherwise, the implementation looks fine to me.
I agree, but I don't think there's a real need for us to hack
drivers/of/fdt_address.c in the meantime -- let's just target upstream
and not carry this in the kernel.
Akashi -- for now, I'll drop the kdump parts of this series which rely
on this helper. The majority of the series is actually independent and
can go in as-is.
I've pushed out a kexec branch to the arm64 tree for you to take a look
at:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kexec
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] meson: Fix IRQ trigger type
From: Emiliano Ingrassia @ 2018-12-06 15:52 UTC (permalink / raw)
To: Carlo Caione, Martin Blumenstingl
Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <85973a9cd43c677ffa5c80853e86d79f36a9eb3a.camel@baylibre.com>
Hi Carlo,
thanks for the answer.
On Thu, Dec 06, 2018 at 01:17:58PM +0000, Carlo Caione wrote:
> On Thu, 2018-12-06 at 13:43 +0100, Emiliano Ingrassia wrote:
> > Hi all,
>
> Hi Emiliano,
>
> > thank you for involving me.
> >
> > I applied Carlo's patches[0] on a kernel vanilla 4.19.6
> > and tested it with kernel packet generator, monitoring
> > bandwidth usage with "nload".
> >
> > All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
> > with a short ethernet cable directly attached to a laptop with
> > 1G ethernet interface, with "nload" running on the board.
> >
> > The tests I performed are composed by the following steps:
> >
> > 1) Start packet generator with "rate 1000M" on laptop;
> >
> > 2) Keep packet generator active on the laptop and
> > start the packet generator on the board with "rate 1000M";
> >
> > 3) Stop both packet generators;
> >
> > 4) Start packet generator on the board;
> >
> > 5) Keep packet generator active on the board and
> > start the packet generator on the laptop.
>
> out of curiosity: why do you expect to see something different from
> point (2)?
>
I did not expect it indeed, I tried and got different results.
> > Test results without Carlo's patches applied:
> >
> > 1) "nload" shows an incoming traffic of ~950Mbps;
> >
> > 2) "nload" shows an incoming traffic of ~400Mbps
> > and an outgoing traffic of ~250Mbps;
> >
> > 3) "nload" shows 0Mbps both for incoming and outgoing traffic;
> >
> > 4) "nload" shows an outgoing traffic of ~950Mbps from the board;
> >
> > 5) "nload" shows incoming traffic of 0Mbps
> > and an outgoing traffic of ~950Mbps.
> >
> > Applying only the first patch (change mac IRQ type) I got the same
> > results.
>
> This is expected. The change in the IRQ type is solving an issue that
> you can see if the run a stress test involving multiple components for
> several hours.
>
OK, did you use "stress-ng" tool for tests?
> > Applying only the second patch (drop eee-broken-1000t) I got the same
> > results!
>
> I am a bit confused here. Wasn't the eee-broken-1000t added to fix a
> problem with the ethernet? Are you suggesting that for some reason you
> cannot reproduce anymore the problem for which the quirk was
> introduced?
>
Problems without the "eee-broken-1000t" flags were experimented
one and a half years ago on a Amlogic development kernel from [0],
probably a 4.14 version.
Many patches about Meson8b SoC, dwmac-meson8b and dwmac driver
were introduced so yes, the "eee-broken-1000t" was added
to fix a problem with the ethernet (one and a half years ago),
but new tests are needed to say if it still necessary.
> > With both patches applied I got the same results but with an incoming
> > traffic
> > of ~3Mbps on the board.
>
> On all the tests and immediately from the start of the tests?
>
Yes, in all the 5 steps immediately from the start.
I also tried to execute "nload" on both sides to see the bandwidth
usage.
With bot patches applied, after starting kernel packet generator
on my laptop with 1Gbps rate, "nload" on the laptop side shows me
an outgoing traffic of ~940Mbps while "nload" on the board side shows
me an incoming traffic of ~3Mbps.
Also consider that a pinging test from my laptop to the board shows
a packet loss of about 90%.
> When you hit the problem con you check in /proc/interrupts if you see
> the IRQ counter for the eth0 incrementing or not?
>
The eth0 IRQ counter is incremented during the test.
> Cheers,
>
> --
> Carlo Caione
>
>
I would like to conduct other tests with iperf3 to be sure about
the obtained results. What do you think?
Should I apply your patches on the latest Amlogic development kernel?
Regards,
Emiliano
[0] https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox