* [PATCH 0/5] ARM: dts: sun8i: Add touchscreen node to various tablets
From: Maxime Ripard @ 2016-09-14 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fee7e6fe-d22b-9233-121e-b403d6ee20f1@redhat.com>
Hi Hans,
On Tue, Sep 13, 2016 at 10:06:56AM +0200, Hans de Goede wrote:
> On 13-09-16 09:59, Maxime Ripard wrote:
> >On Sun, Sep 11, 2016 at 08:23:22PM +0200, Hans de Goede wrote:
> >>Hi Maxime,
> >>
> >>Now that Dmitry has queued up the firmware-name property changes
> >>in his for-linus branch, these dt patches are ready for merging.
> >
> >I queued this for 4.10.
>
> 4.10 ? Is next already frozen ? Note either way is fine
> just wondering.
Yes, the arm-soc maintainers usually stop merging PR after -rc6. It's
still a bit flexible is something major and not really huge comes up,
but for that kind of patches, I usually start queuing patches for the
next release when -rc6 is out.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160914/0586166c/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/6] usb: dwc2: add support for Meson8b and GXBB SoCs
From: Kevin Hilman @ 2016-09-14 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911134111.31141-2-martin.blumenstingl@googlemail.com>
Hi John,
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> From: Jerome Brunet <jbrunet@baylibre.com>
>
> Add compatible strings for amlogic Meson8b and GXBB SoCs with the
> corresponding configuration parameters.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Are you OK with adding this platform for v4.9? I know you mentioned
you're working on new bindings to replace the current way, but since
that hasn't been posted AFAICT, it would be nice to get this merged now
and we can help test the new bindings when you're ready.
If you're OK with that, and with your Ack, I can take merge the driver
changes through the arm-soc tree along with the rest of the DT patches.
Kevin
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++
> drivers/usb/dwc2/platform.c | 34 ++++++++++++++++++++++++++
> 2 files changed, 36 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
> index 20a68bf..2c30a54 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -10,6 +10,8 @@ Required properties:
> - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc;
> - "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs;
> - "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
> + - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
> + - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
> - snps,dwc2: A generic DWC2 USB controller with default parameters.
> - reg : Should contain 1 register range (address and length)
> - interrupts : Should contain 1 interrupt
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index fc6f525..8f7b34c 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -181,6 +181,38 @@ static const struct dwc2_core_params params_ltq = {
> .hibernation = -1,
> };
>
> +static const struct dwc2_core_params params_amlogic = {
> + .otg_cap = DWC2_CAP_PARAM_NO_HNP_SRP_CAPABLE,
> + .otg_ver = -1,
> + .dma_enable = 1,
> + .dma_desc_enable = 0,
> + .dma_desc_fs_enable = 0,
> + .speed = DWC2_SPEED_PARAM_HIGH,
> + .enable_dynamic_fifo = 1,
> + .en_multiple_tx_fifo = -1,
> + .host_rx_fifo_size = 512,
> + .host_nperio_tx_fifo_size = 500,
> + .host_perio_tx_fifo_size = 500,
> + .max_transfer_size = -1,
> + .max_packet_count = -1,
> + .host_channels = 16,
> + .phy_type = DWC2_PHY_TYPE_PARAM_UTMI,
> + .phy_utmi_width = -1,
> + .phy_ulpi_ddr = -1,
> + .phy_ulpi_ext_vbus = -1,
> + .i2c_enable = -1,
> + .ulpi_fs_ls = -1,
> + .host_support_fs_ls_low_power = -1,
> + .host_ls_low_power_phy_clk = -1,
> + .ts_dline = -1,
> + .reload_ctl = 1,
> + .ahbcfg = GAHBCFG_HBSTLEN_INCR8 <<
> + GAHBCFG_HBSTLEN_SHIFT,
> + .uframe_sched = 0,
> + .external_id_pin_ctl = -1,
> + .hibernation = -1,
> +};
> +
> /*
> * Check the dr_mode against the module configuration and hardware
> * capabilities.
> @@ -464,6 +496,8 @@ static const struct of_device_id dwc2_of_match_table[] = {
> { .compatible = "lantiq,xrx200-usb", .data = ¶ms_ltq },
> { .compatible = "snps,dwc2", .data = NULL },
> { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
> + { .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
> + { .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
> {},
> };
> MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
^ permalink raw reply
* [PATCH v2 3/6] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kevin Hilman @ 2016-09-14 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911134111.31141-4-martin.blumenstingl@googlemail.com>
Kishon,
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> This is a new driver for the USB PHY found in Meson8b and GXBB SoCs.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> Tested-by: Kevin Hilman <khilman@baylibre.com>
Will you be picking this up for v4.9?
Kevin
> ---
> drivers/phy/Kconfig | 11 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-meson-usb2.c | 280 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 292 insertions(+)
> create mode 100644 drivers/phy/phy-meson-usb2.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 19bff3a..6ad87ec 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -453,4 +453,15 @@ config PHY_NS2_PCIE
> help
> Enable this to support the Broadcom Northstar2 PCIe PHY.
> If unsure, say N.
> +
> +config PHY_MESON_USB2
> + tristate "Meson USB2 PHY driver"
> + default ARCH_MESON
> + depends on OF && (ARCH_MESON || COMPILE_TEST)
> + select GENERIC_PHY
> + help
> + Enable this to support the Meson USB2 PHYs found in Meson8b
> + and GXBB SoCs.
> + If unsure, say N.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 90ae198..dd507ac 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -56,3 +56,4 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
> obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
> +obj-$(CONFIG_PHY_MESON_USB2) += phy-meson-usb2.o
> diff --git a/drivers/phy/phy-meson-usb2.c b/drivers/phy/phy-meson-usb2.c
> new file mode 100644
> index 0000000..eece521
> --- /dev/null
> +++ b/drivers/phy/phy-meson-usb2.c
> @@ -0,0 +1,280 @@
> +/*
> + * Meson USB2 PHY driver
> + *
> + * Copyright (C) 2016 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/reset.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/usb/of.h>
> +
> +#define REG_CONFIG 0x00
> + #define REG_CONFIG_CLK_EN BIT(0)
> + #define REG_CONFIG_CLK_SEL_MASK GENMASK(3, 1)
> + #define REG_CONFIG_CLK_DIV_MASK GENMASK(10, 4)
> + #define REG_CONFIG_CLK_32k_ALTSEL BIT(15)
> + #define REG_CONFIG_TEST_TRIG BIT(31)
> +
> +#define REG_CTRL 0x04
> + #define REG_CTRL_SOFT_PRST BIT(0)
> + #define REG_CTRL_SOFT_HRESET BIT(1)
> + #define REG_CTRL_SS_SCALEDOWN_MODE_MASK GENMASK(3, 2)
> + #define REG_CTRL_CLK_DET_RST BIT(4)
> + #define REG_CTRL_INTR_SEL BIT(5)
> + #define REG_CTRL_CLK_DETECTED BIT(8)
> + #define REG_CTRL_SOF_SENT_RCVD_TGL BIT(9)
> + #define REG_CTRL_SOF_TOGGLE_OUT BIT(10)
> + #define REG_CTRL_POWER_ON_RESET BIT(15)
> + #define REG_CTRL_SLEEPM BIT(16)
> + #define REG_CTRL_TX_BITSTUFF_ENN_H BIT(17)
> + #define REG_CTRL_TX_BITSTUFF_ENN BIT(18)
> + #define REG_CTRL_COMMON_ON BIT(19)
> + #define REG_CTRL_REF_CLK_SEL_MASK GENMASK(21, 20)
> + #define REG_CTRL_REF_CLK_SEL_SHIFT 20
> + #define REG_CTRL_FSEL_MASK GENMASK(24, 22)
> + #define REG_CTRL_FSEL_SHIFT 22
> + #define REG_CTRL_PORT_RESET BIT(25)
> + #define REG_CTRL_THREAD_ID_MASK GENMASK(31, 26)
> +
> +#define REG_ENDP_INTR 0x08
> +
> +/* bits [31:26], [24:21] and [15:3] seem to be read-only */
> +#define REG_ADP_BC 0x0c
> + #define REG_ADP_BC_VBUS_VLD_EXT_SEL BIT(0)
> + #define REG_ADP_BC_VBUS_VLD_EXT BIT(1)
> + #define REG_ADP_BC_OTG_DISABLE BIT(2)
> + #define REG_ADP_BC_ID_PULLUP BIT(3)
> + #define REG_ADP_BC_DRV_VBUS BIT(4)
> + #define REG_ADP_BC_ADP_PRB_EN BIT(5)
> + #define REG_ADP_BC_ADP_DISCHARGE BIT(6)
> + #define REG_ADP_BC_ADP_CHARGE BIT(7)
> + #define REG_ADP_BC_SESS_END BIT(8)
> + #define REG_ADP_BC_DEVICE_SESS_VLD BIT(9)
> + #define REG_ADP_BC_B_VALID BIT(10)
> + #define REG_ADP_BC_A_VALID BIT(11)
> + #define REG_ADP_BC_ID_DIG BIT(12)
> + #define REG_ADP_BC_VBUS_VALID BIT(13)
> + #define REG_ADP_BC_ADP_PROBE BIT(14)
> + #define REG_ADP_BC_ADP_SENSE BIT(15)
> + #define REG_ADP_BC_ACA_ENABLE BIT(16)
> + #define REG_ADP_BC_DCD_ENABLE BIT(17)
> + #define REG_ADP_BC_VDAT_DET_EN_B BIT(18)
> + #define REG_ADP_BC_VDAT_SRC_EN_B BIT(19)
> + #define REG_ADP_BC_CHARGE_SEL BIT(20)
> + #define REG_ADP_BC_CHARGE_DETECT BIT(21)
> + #define REG_ADP_BC_ACA_PIN_RANGE_C BIT(22)
> + #define REG_ADP_BC_ACA_PIN_RANGE_B BIT(23)
> + #define REG_ADP_BC_ACA_PIN_RANGE_A BIT(24)
> + #define REG_ADP_BC_ACA_PIN_GND BIT(25)
> + #define REG_ADP_BC_ACA_PIN_FLOAT BIT(26)
> +
> +#define REG_DBG_UART 0x14
> +
> +#define REG_TEST 0x18
> + #define REG_TEST_DATA_IN_MASK GENMASK(3, 0)
> + #define REG_TEST_EN_MASK GENMASK(7, 4)
> + #define REG_TEST_ADDR_MASK GENMASK(11, 8)
> + #define REG_TEST_DATA_OUT_SEL BIT(12)
> + #define REG_TEST_CLK BIT(13)
> + #define REG_TEST_VA_TEST_EN_B_MASK GENMASK(15, 14)
> + #define REG_TEST_DATA_OUT_MASK GENMASK(19, 16)
> + #define REG_TEST_DISABLE_ID_PULLUP BIT(20)
> +
> +#define REG_TUNE 0x1c
> + #define REG_TUNE_TX_RES_TUNE_MASK GENMASK(1, 0)
> + #define REG_TUNE_TX_HSXV_TUNE_MASK GENMASK(3, 2)
> + #define REG_TUNE_TX_VREF_TUNE_MASK GENMASK(7, 4)
> + #define REG_TUNE_TX_RISE_TUNE_MASK GENMASK(9, 8)
> + #define REG_TUNE_TX_PREEMP_PULSE_TUNE BIT(10)
> + #define REG_TUNE_TX_PREEMP_AMP_TUNE_MASK GENMASK(12, 11)
> + #define REG_TUNE_TX_FSLS_TUNE_MASK GENMASK(16, 13)
> + #define REG_TUNE_SQRX_TUNE_MASK GENMASK(19, 17)
> + #define REG_TUNE_OTG_TUNE GENMASK(22, 20)
> + #define REG_TUNE_COMP_DIS_TUNE GENMASK(25, 23)
> + #define REG_TUNE_HOST_DM_PULLDOWN BIT(26)
> + #define REG_TUNE_HOST_DP_PULLDOWN BIT(27)
> +
> +#define RESET_COMPLETE_TIME 500
> +#define ACA_ENABLE_COMPLETE_TIME 50
> +
> +struct phy_meson_usb2_priv {
> + void __iomem *regs;
> + enum usb_dr_mode dr_mode;
> + struct clk *clk_usb_general;
> + struct clk *clk_usb;
> +};
> +
> +static u32 phy_meson_usb2_read(struct phy_meson_usb2_priv *phy_priv, u32 reg)
> +{
> + return readl(phy_priv->regs + reg);
> +}
> +
> +static void phy_meson_usb2_mask_bits(struct phy_meson_usb2_priv *phy_priv,
> + u32 reg, u32 mask, u32 value)
> +{
> + u32 data;
> +
> + data = phy_meson_usb2_read(phy_priv, reg);
> + data &= ~mask;
> + data |= (value & mask);
> +
> + writel(data, phy_priv->regs + reg);
> +}
> +
> +static int phy_meson_usb2_power_on(struct phy *phy)
> +{
> + struct phy_meson_usb2_priv *priv = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = clk_prepare_enable(priv->clk_usb_general);
> + if (ret) {
> + dev_err(&phy->dev, "Failed to enable USB general clock\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(priv->clk_usb);
> + if (ret) {
> + dev_err(&phy->dev, "Failed to enable USB DDR clock\n");
> + return ret;
> + }
> +
> + phy_meson_usb2_mask_bits(priv, REG_CONFIG, REG_CONFIG_CLK_32k_ALTSEL,
> + REG_CONFIG_CLK_32k_ALTSEL);
> +
> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_REF_CLK_SEL_MASK,
> + 0x2 << REG_CTRL_REF_CLK_SEL_SHIFT);
> +
> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_FSEL_MASK,
> + 0x5 << REG_CTRL_FSEL_SHIFT);
> +
> + /* reset the PHY */
> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_POWER_ON_RESET,
> + REG_CTRL_POWER_ON_RESET);
> + udelay(RESET_COMPLETE_TIME);
> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_POWER_ON_RESET, 0);
> + udelay(RESET_COMPLETE_TIME);
> +
> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_SOF_TOGGLE_OUT,
> + REG_CTRL_SOF_TOGGLE_OUT);
> +
> + if (priv->dr_mode == USB_DR_MODE_HOST) {
> + phy_meson_usb2_mask_bits(priv, REG_ADP_BC,
> + REG_ADP_BC_ACA_ENABLE,
> + REG_ADP_BC_ACA_ENABLE);
> +
> + udelay(ACA_ENABLE_COMPLETE_TIME);
> +
> + if (phy_meson_usb2_read(priv, REG_ADP_BC) &
> + REG_ADP_BC_ACA_PIN_FLOAT) {
> + dev_warn(&phy->dev, "USB ID detect failed!\n");
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int phy_meson_usb2_power_off(struct phy *phy)
> +{
> + struct phy_meson_usb2_priv *priv = phy_get_drvdata(phy);
> +
> + clk_disable_unprepare(priv->clk_usb);
> + clk_disable_unprepare(priv->clk_usb_general);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops phy_meson_usb2_ops = {
> + .power_on = phy_meson_usb2_power_on,
> + .power_off = phy_meson_usb2_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int phy_meson_usb2_probe(struct platform_device *pdev)
> +{
> + struct phy_meson_usb2_priv *priv;
> + struct resource *res;
> + struct phy *phy;
> + struct phy_provider *phy_provider;
> + int ret;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(priv->regs))
> + return PTR_ERR(priv->regs);
> +
> + priv->clk_usb_general = devm_clk_get(&pdev->dev, "usb_general");
> + if (IS_ERR(priv->clk_usb_general))
> + return PTR_ERR(priv->clk_usb_general);
> +
> + priv->clk_usb = devm_clk_get(&pdev->dev, "usb");
> + if (IS_ERR(priv->clk_usb))
> + return PTR_ERR(priv->clk_usb);
> +
> + priv->dr_mode = of_usb_get_dr_mode_by_phy(pdev->dev.of_node, -1);
> + if (priv->dr_mode == USB_DR_MODE_UNKNOWN) {
> + dev_err(&pdev->dev,
> + "missing dual role configuration of the controller\n");
> + return -EINVAL;
> + }
> +
> + phy = devm_phy_create(&pdev->dev, NULL, &phy_meson_usb2_ops);
> + if (IS_ERR(phy)) {
> + dev_err(&pdev->dev, "failed to create PHY\n");
> + return PTR_ERR(phy);
> + }
> +
> + /*
> + * No actual error check here because the hardware only has one reset
> + * line for both PHYs. Using a shared reset is not possible because we
> + * must call reset_control_reset to trigger the reset (which is not
> + * allowed for shared resets in the reset framework).
> + */
> + ret = device_reset_optional(&pdev->dev);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> + phy_set_drvdata(phy, priv);
> +
> + phy_provider =
> + devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
> +
> + return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct of_device_id phy_meson_usb2_of_match[] = {
> + { .compatible = "amlogic,meson8b-usb2-phy", },
> + { .compatible = "amlogic,meson-gxbb-usb2-phy", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, phy_meson_usb2_of_match);
> +
> +static struct platform_driver phy_meson_usb2_driver = {
> + .probe = phy_meson_usb2_probe,
> + .driver = {
> + .name = "phy-meson-usb2",
> + .of_match_table = phy_meson_usb2_of_match,
> + },
> +};
> +module_platform_driver(phy_meson_usb2_driver);
> +
> +MODULE_AUTHOR("Martin Blumenstingl <martin.blumenstingl@googlemail.com>");
> +MODULE_DESCRIPTION("Meson USB2 PHY driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* [PATCH v1 2/3] ARM: dts: imx6q-apalis-ixora: Remove use of pwm-leds
From: Stefan Agner @ 2016-09-14 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6111feb57b5fbaa29eeb6ba089bb2824bbf2f8ff.1473833908.git.maitysanchayan@gmail.com>
On 2016-09-13 23:35, Sanchayan Maity wrote:
> Remove use of pwm-leds and use the standard /sys/class/pwm
> interface from PWM subsystem.
Don't we have actual leds on the Ixora?
--
Stefan
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> arch/arm/boot/dts/imx6q-apalis-ixora.dts | 22 ----------------------
> 1 file changed, 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index d99979e..70a3da0 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -146,28 +146,6 @@
> gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
> };
> };
> -
> - pwmleds {
> - compatible = "pwm-leds";
> -
> - ledpwm1 {
> - label = "PWM1";
> - pwms = <&pwm1 0 50000>;
> - max-brightness = <255>;
> - };
> -
> - ledpwm2 {
> - label = "PWM2";
> - pwms = <&pwm2 0 50000>;
> - max-brightness = <255>;
> - };
> -
> - ledpwm3 {
> - label = "PWM3";
> - pwms = <&pwm3 0 50000>;
> - max-brightness = <255>;
> - };
> - };
> };
>
> &backlight {
^ permalink raw reply
* [GIT PULL] Integrator cleanups and DTS
From: Arnd Bergmann @ 2016-09-14 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYBB0rw3uQZnmpsuc_=mf5Ra-HmbRfdm6aT0kn9rn41Lg@mail.gmail.com>
On Wednesday, August 31, 2016 9:44:55 AM CEST Linus Walleij wrote:
> Hi ARM SoC people,
>
> this is a request to pull a combined cleanup and DTS changes batch
> for the Integrators.
>
> Since I have commits such as "move CLCD display to DTS" that is
> a single functional change deleting stuff from the boardfile and adding
> the same to the DTS, it is a combination of DTS and boardfile patches.
> All with the goal to cut down on boardfile code and move to device tree.
>
> The changes require the corresponding changes from the video/fbdev
> and clk subsystems to come in, but these are orthogonal and depend
> solely on the DTS things coming in place. As the DTS repository is
> "kind of external" I am deliverately relaxed about synchronizing changes
> here and just optimistically assume they will come in during the merge
> window and start working.
>
> There are no compile-time dependencies on fbdev or clk, just runtime,
> with the DT changes. This cleanup can be merged totally orthogonally,
> and when ARM SoC, fbdev and clk are all merged in the merge window,
> the result will compile and boot nicely.
>
> I don't expect any conflicting changes to the Integrator in this merge
> window, neither to board files nor DTS.
>
I've put this into next/late since it's not just dts changes. I considered
putting it into next/cleanup, but then again it's also not just cleanups.
Given the dependency on the fbdev and clk trees, next/late seems appropriate
anyway, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/3] DaVinci dts updates for v4.9
From: Arnd Bergmann @ 2016-09-14 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160824110006.1866-2-nsekhar@ti.com>
On Wednesday, August 24, 2016 4:30:05 PM CEST Sekhar Nori wrote:
> DaVinci DA850 device-tree enhancements include:
>
> - Support for new board OMAP-L138 LCDK
> - Add AEMIF node on DA850 EVM and use it for NAND
> - Audio support for LCDK
> - Cleanups for PWM and UART
>
>
This one fails to build:
ERROR (phandle_references): Reference to non-existent node or label "nand_cs3_pins"
ERROR: Input tree has errors, aborting (use -f to force output)
DTC arch/arm/boot/dts/bcm47081-asus-rt-n18u.dtb
Can you send a fixed version please?
Arnd
^ permalink raw reply
* [PATCH v4 07/10] ARM: Introduce MPIDR_LEVEL_SHIFT macro
From: Marc Zyngier @ 2016-09-14 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D96B02.6060209@arm.com>
On 14/09/16 16:21, Vladimir Murzin wrote:
> On 13/09/16 11:44, Marc Zyngier wrote:
>> On 13/09/16 11:32, Vladimir Murzin wrote:
>>> On 13/09/16 11:12, Marc Zyngier wrote:
>>>> On 13/09/16 10:04, Vladimir Murzin wrote:
>>>>> On 13/09/16 09:38, Christoffer Dall wrote:
>>>>>> On Mon, Sep 12, 2016 at 03:49:21PM +0100, Vladimir Murzin wrote:
>>>>>>> vgic-v3 driver uses architecture specific MPIDR_LEVEL_SHIFT macro to
>>>>>>> encode the affinity in a form compatible with ICC_SGI* registers.
>>>>>>> Unfortunately, that macro is missing on ARM, so let's add it.
>>>>>>>
>>>>>>> Cc: Russell King <rmk+kernel@armlinux.org.uk>
>>>>>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>>>>>> ---
>>>>>>> arch/arm/include/asm/cputype.h | 1 +
>>>>>>> 1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
>>>>>>> index 1ee94c7..e2d94c1 100644
>>>>>>> --- a/arch/arm/include/asm/cputype.h
>>>>>>> +++ b/arch/arm/include/asm/cputype.h
>>>>>>> @@ -55,6 +55,7 @@
>>>>>>>
>>>>>>> #define MPIDR_LEVEL_BITS 8
>>>>>>> #define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
>>>>>>> +#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * level)
>>>>>>>
>>>>>>
>>>>>> I'm not sure I follow the correctness of this completely.
>>>>>>
>>>>>> This is called from vgic_v3_dispatch_sgi, which takes a u64 value, which
>>>>>> may have something in the Aff3 field, which we now shift left 24 bits,
>>>>>> but that is not the Aff3 field of AArch32's MPIDR.
>>>>>>
>>>>>> What is the rationale for this making sense again?
>>>>>
>>>>> IIUC, in such case we construct mpidr which won't match in match_mpidr()
>>>>> with the value we get from kvm_vcpu_get_mpidr_aff() and no SGI will be
>>>>> sent to the guest.
>>>>>
>>>>> Since we get that u64 value from the guest, I'd think it is something
>>>>> wrong is going on in the guest in case Aff3 is non-zero; however, we can
>>>>> hide it by zeroing out SGI Aff3 bits in access_gic_sgi().
>>>>
>>>> I don't think zeroing Aff3 is the right move, as the spec doesn't say
>>>> that Aff3 should be ignored in a write to ICC_SGI1R. On the other hand,
>>>> the spec says (in the context of the target list): "If a bit is 1 and
>>>> the bit does not correspond to a valid target PE, the bit must be
>>>> ignored by the Distributor".
>>>>
>>>> This makes me think that, unless ICC_SGI1R.IMR is set, we should simply
>>>> ignore that SGI because there is no way we can actually deliver it.
>>>>
>>>> Could you cook a small patch that would go on top of this series?
>>>
>>> I assume you've meant ICC_SGI1R.IRM, aka broadcast. In this case,
>>
>> Yes, sorry.
>>
>>> vgic_v3_dispatch_sgi() seems already matches the logic you've described:
>>>
>>> - if IRM == 1, send to everyone except self without check for mpidr
>>> - if IRM == 0, send to target iff matched to a valid mpidr
>>>
>>> Am I missing something?
>>
>> Not much. My only ask was that if Aff3 was set, we could take the
>> shortcut of not calling vgic_v3_dispatch_sgi() at all and return
>> immediately. But as you said, we already deal with the case of invalid
>> MPIDRs.
>>
>
> Anything I can do to make this patch better?
I'm OK with it as it is. The shortcut doesn't bring anything useful, so
let's not optimise for an invalid case.
FWIW: Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 01/10] arm64: KVM: Use static keys for selecting the GIC backend
From: Marc Zyngier @ 2016-09-14 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D96AA0.2010607@arm.com>
On 14/09/16 16:20, Vladimir Murzin wrote:
> On 13/09/16 10:22, Christoffer Dall wrote:
>> On Tue, Sep 13, 2016 at 10:11:10AM +0100, Marc Zyngier wrote:
>>> On 13/09/16 09:20, Christoffer Dall wrote:
>>>> On Mon, Sep 12, 2016 at 03:49:15PM +0100, Vladimir Murzin wrote:
>>>>> Currently GIC backend is selected via alternative framework and this
>>>>> is fine. We are going to introduce vgic-v3 to 32-bit world and there
>>>>> we don't have patching framework in hand, so we can either check
>>>>> support for GICv3 every time we need to choose which backend to use or
>>>>> try to optimise it by using static keys. The later looks quite
>>>>> promising because we can share logic involved in selecting GIC backend
>>>>> between architectures if both uses static keys.
>>>>>
>>>>> This patch moves arm64 from alternative to static keys framework for
>>>>> selecting GIC backend. For that we embed static key into vgic_global
>>>>> and enable the key during vgic initialisation based on what has
>>>>> already been exposed by the host GIC driver.
>>>>>
>>>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>>>> ---
>>>>> arch/arm64/kvm/hyp/switch.c | 21 +++++++++++----------
>>>>> include/kvm/arm_vgic.h | 4 ++++
>>>>> virt/kvm/arm/vgic/vgic-init.c | 4 ++++
>>>>> virt/kvm/arm/vgic/vgic.c | 2 +-
>>>>> 4 files changed, 20 insertions(+), 11 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>>>>> index 5a84b45..d5c4cc5 100644
>>>>> --- a/arch/arm64/kvm/hyp/switch.c
>>>>> +++ b/arch/arm64/kvm/hyp/switch.c
>>>>> @@ -16,6 +16,8 @@
>>>>> */
>>>>>
>>>>> #include <linux/types.h>
>>>>> +#include <linux/jump_label.h>
>>>>> +
>>>>> #include <asm/kvm_asm.h>
>>>>> #include <asm/kvm_hyp.h>
>>>>>
>>>>> @@ -126,17 +128,13 @@ static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
>>>>> write_sysreg(0, vttbr_el2);
>>>>> }
>>>>>
>>>>> -static hyp_alternate_select(__vgic_call_save_state,
>>>>> - __vgic_v2_save_state, __vgic_v3_save_state,
>>>>> - ARM64_HAS_SYSREG_GIC_CPUIF);
>>>>> -
>>>>> -static hyp_alternate_select(__vgic_call_restore_state,
>>>>> - __vgic_v2_restore_state, __vgic_v3_restore_state,
>>>>> - ARM64_HAS_SYSREG_GIC_CPUIF);
>>>>> -
>>>>> static void __hyp_text __vgic_save_state(struct kvm_vcpu *vcpu)
>>>>> {
>>>>> - __vgic_call_save_state()(vcpu);
>>>>> + if (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
>>>>
>>>> It's a bit weird that we use _unlikely for GICv3 (at least if/when GICv3
>>>> hardware becomes mainstream), but as we don't have another primitive for
>>>> the 'default disabled' case, I suppose that's the best we can do.
>>>
>>> We could always revert the "likelihood" of that test once GICv3 has
>>> conquered the world. Or start patching the 32bit kernel like we do for
>>> 64bit...
>>>
>>>>
>>>>> + __vgic_v3_save_state(vcpu);
>>>>> + else
>>>>> + __vgic_v2_save_state(vcpu);
>>>>> +
>>>>> write_sysreg(read_sysreg(hcr_el2) & ~HCR_INT_OVERRIDE, hcr_el2);
>>>>> }
>>>>>
>>>>> @@ -149,7 +147,10 @@ static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
>>>>> val |= vcpu->arch.irq_lines;
>>>>> write_sysreg(val, hcr_el2);
>>>>>
>>>>> - __vgic_call_restore_state()(vcpu);
>>>>> + if (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
>>>>> + __vgic_v3_restore_state(vcpu);
>>>>> + else
>>>>> + __vgic_v2_restore_state(vcpu);
>>>>> }
>>>>>
>>>>> static bool __hyp_text __true_value(void)
>>>>> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>>>>> index 19b698e..994665a 100644
>>>>> --- a/include/kvm/arm_vgic.h
>>>>> +++ b/include/kvm/arm_vgic.h
>>>>> @@ -23,6 +23,7 @@
>>>>> #include <linux/types.h>
>>>>> #include <kvm/iodev.h>
>>>>> #include <linux/list.h>
>>>>> +#include <linux/jump_label.h>
>>>>>
>>>>> #define VGIC_V3_MAX_CPUS 255
>>>>> #define VGIC_V2_MAX_CPUS 8
>>>>> @@ -63,6 +64,9 @@ struct vgic_global {
>>>>>
>>>>> /* Only needed for the legacy KVM_CREATE_IRQCHIP */
>>>>> bool can_emulate_gicv2;
>>>>> +
>>>>> + /* GIC system register CPU interface */
>>>>> + struct static_key_false gicv3_cpuif;
>>>>
>>>> Documentation/static-keys.txt says that we are not supposed to use
>>>> struct static_key_false directly. This will obviously work quite
>>>> nicely, but we could consider adding a pair of
>>>> DECLARE_STATIC_KEY_TRUE/FALSE macros that don't have the assignments,
>>>> but obviously this will need an ack from other maintainers.
>>>>
>>>> Thoughts?
>>>
>>> Grepping through the tree shows that we're not the only abusers of this
>>> (dynamic debug is far worse!). Happy to write the additional macros and
>>> submit them if nobody beats me to it.
>>>
>>>>
>>>>
>>>>> };
>>>>>
>>>>> extern struct vgic_global kvm_vgic_global_state;
>>>>> diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
>>>>> index 83777c1..14d6718 100644
>>>>> --- a/virt/kvm/arm/vgic/vgic-init.c
>>>>> +++ b/virt/kvm/arm/vgic/vgic-init.c
>>>>> @@ -405,6 +405,10 @@ int kvm_vgic_hyp_init(void)
>>>>> break;
>>>>> case GIC_V3:
>>>>> ret = vgic_v3_probe(gic_kvm_info);
>>>>> + if (!ret) {
>>>>> + static_branch_enable(&kvm_vgic_global_state.gicv3_cpuif);
>>>>> + kvm_info("GIC system register CPU interface\n");
>>>>
>>>> nit: add enabled to the info message?
>>>>
>>>>> + }
>>>>> break;
>>>>> default:
>>>>> ret = -ENODEV;
>>>>> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
>>>>> index e83b7fe..8a529a7 100644
>>>>> --- a/virt/kvm/arm/vgic/vgic.c
>>>>> +++ b/virt/kvm/arm/vgic/vgic.c
>>>>> @@ -29,7 +29,7 @@
>>>>> #define DEBUG_SPINLOCK_BUG_ON(p)
>>>>> #endif
>>>>>
>>>>> -struct vgic_global __section(.hyp.text) kvm_vgic_global_state;
>>>>> +struct vgic_global __section(.hyp.text) kvm_vgic_global_state = {.gicv3_cpuif = STATIC_KEY_FALSE_INIT,};
>>>>>
>>>>> /*
>>>>> * Locking order is always:
>>>>> --
>>>>> 1.7.9.5
>>>>>
>>>>
>>>> Overall this looks really nice, as long as we're clear on the static
>>>> keys stuff.
>>>
>>> Indeed, we should get this sorted, though I'm not sure this should be a
>>> blocker for this code.
>>>
>> Agreed, let's ship it!
>
> To make it clear, should I respin with "enabled" into the info message
> and macros for static keys?
I think we can fix the message up when applying the patches. As for the
macros, we should have a separate series that does it treewide.
Christoffer?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] ARM64: Xilinx ZynqMP DT changes for v4.9
From: Arnd Bergmann @ 2016-09-14 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <066cb4a0-d823-f940-5189-95302f098fd5@monstr.eu>
On Friday, August 19, 2016 12:40:12 PM CEST Michal Simek wrote:
> arm64: Xilinx ZynqMP dt patches for v4.9
>
> - Fix gic ranges property
> - Use 64bit size cells format
> - Add PCIe node
> - Correct pmu and watchdog nodes
>
>
Pulled into next/dt64, sorry for the delay, and thanks for the
reminder.
Arnd
^ permalink raw reply
* [RFC PATCH v2 05/11] ACPI: platform: setup MSI domain for ACPI based platform device
From: Marc Zyngier @ 2016-09-14 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473862879-7769-6-git-send-email-guohanjun@huawei.com>
On 14/09/16 15:21, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the platform msi domain created, we can set up the msi domain
> for a platform device when it's probed.
>
> This patch introduces acpi_configure_msi_domain(), which retrieves
> the domain from iort and set it to platform device.
>
> As some platform devices such as an irqchip needs the msi irqdomain
> to be the interrupt parent domain, we need to get irqdomain before
> platform device is probed.
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> drivers/acpi/arm64/iort.c | 5 ++++-
> drivers/base/platform-msi.c | 15 ++++++++++++++-
> drivers/base/platform.c | 2 ++
> include/linux/msi.h | 1 +
> 4 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 13a1905..bccd3cc 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -478,6 +478,7 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
> {
> struct fwnode_handle *handle;
> int its_id;
> + enum irq_domain_bus_token bus_token;
>
> if (iort_dev_find_its_id(dev, req_id, 0, &its_id))
> return NULL;
> @@ -486,7 +487,9 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
> if (!handle)
> return NULL;
>
> - return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
> + bus_token = dev_is_pci(dev) ?
> + DOMAIN_BUS_PCI_MSI : DOMAIN_BUS_PLATFORM_MSI;
> + return irq_find_matching_fwnode(handle, bus_token);
> }
>
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
> index 279e539..f6eae18 100644
> --- a/drivers/base/platform-msi.c
> +++ b/drivers/base/platform-msi.c
> @@ -17,8 +17,8 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/acpi_iort.h>
> #include <linux/device.h>
> -#include <linux/idr.h>
> #include <linux/irq.h>
> #include <linux/irqdomain.h>
> #include <linux/msi.h>
> @@ -416,3 +416,16 @@ int platform_msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
>
> return err;
> }
> +
> +int acpi_configure_msi_domain(struct device *dev)
> +{
> + struct irq_domain *d = NULL;
> +
> + d = iort_get_device_domain(dev, 0);
This looks completely wrong. Why RID 0? As far as I can see, 0 is not a
special value, and could be something else.
> + if (d) {
> + dev_set_msi_domain(dev, d);
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
I really hate this, as the platform MSI code is intentionally free of
any firmware reference. This should live in the ACPI code.
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 6482d47..ea01a37 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -24,6 +24,7 @@
> #include <linux/pm_domain.h>
> #include <linux/idr.h>
> #include <linux/acpi.h>
> +#include <linux/msi.h>
> #include <linux/clk/clk-conf.h>
> #include <linux/limits.h>
> #include <linux/property.h>
> @@ -500,6 +501,7 @@ struct platform_device *platform_device_register_full(
> pdev->dev.parent = pdevinfo->parent;
> pdev->dev.fwnode = pdevinfo->fwnode;
>
> + acpi_configure_msi_domain(&pdev->dev);
It feels odd to put this in the generic code, while you could perfectly
put the call into acpi_platform.c and keep the firmware stuff away from
the generic code.
> if (pdevinfo->dma_mask) {
> /*
> * This memory isn't freed when the device is put,
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index e8c81fb..1e93a78 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -308,6 +308,7 @@ int platform_msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
> void platform_msi_domain_free(struct irq_domain *domain, unsigned int virq,
> unsigned int nvec);
> void *platform_msi_get_host_data(struct irq_domain *domain);
> +int acpi_configure_msi_domain(struct device *dev);
> #endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
>
> #ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.9
From: Arnd Bergmann @ 2016-09-14 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1473320411.git.horms+renesas@verge.net.au>
On Thursday, September 8, 2016 9:43:24 AM CEST Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM64 based SoC DT updates for v4.9.
>
> This pull request is based on the sh-pfc-for-v4.9-tag2 of
> Geert Uytterhoeven's renesas-driver's tree which is included in the
> devel and for-next branches of Linus Walleij's linux-pinctrl tree.
>
>
Pulled into next/late because of the dependency.
We'll send it during the merge window after the dependencies
are all merged upstream. Thanks,
Arnd
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT changes for v4.9
From: Arnd Bergmann @ 2016-09-14 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h7fat25g4.fsf@baylibre.com>
On Friday, September 2, 2016 5:27:23 PM CEST Kevin Hilman wrote:
> The pull request below is for the DT changes for 64-bit Amlogic
> platforms.
>
> The DT additions for the new clock/reset support are dependent on DT
> bindings/includes that were merged via the clock tree, so this branch
> includes a merge of an immtable branch (clk/clk-gxbb-meson-ao) from the
> clock tree to handle those dependencies.
>
> Due to the dependency, it's fine with me if this goes into next/late
> instead of next/dt64.
>
Pulled into next/late, thanks!
Arnd
^ permalink raw reply
* [RESEND PATCH v4] thermal: tango: add resume support
From: Marc Gonzalez @ 2016-09-14 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6763387.6QdSyfOt0d@wuerfel>
On 07/09/2016 10:55, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 10:30:41 AM CEST Marc Gonzalez wrote:
>
>> When this platform is suspended, firmware powers the entire SoC down,
>> except a few hardware blocks waiting for wakeup events. There is no
>> context to save for this particular block.
>>
>> Therefore, there is nothing useful for the driver to do on suspend;
>> so we define a NULL suspend hook. On resume, the driver initializes
>> the block exactly as is done in the probe callback.
>>
>> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
>> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Hello Rui, Eduardo,
The present patch has been reviewed by both Kevin Hilman and Arnd Bergmann,
two arm-soc maintainers. Can you pick it up in time for inclusion in v4.9?
Regards.
^ permalink raw reply
* [GIT PULL] ARM: mvebu: drivers for v4.9 (#1)
From: Gregory CLEMENT @ 2016-09-14 15:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for drivers for mvebu for v4.9.
Gregory
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-drivers-4.9-1
for you to fetch changes up to e8f3f276d974b55554cbd47af024b29a576b0e59:
pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181 (2016-09-14 16:02:45 +0200)
----------------------------------------------------------------
mvebu drivers for 4.9 (part 1)
- Add pinctrl and clk support for the Orion5x SoC mv88f5181 variant
----------------------------------------------------------------
Jamie Lentin (2):
clk: mvebu: Add clk support for the orion5x SoC mv88f5181
pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181
.../devicetree/bindings/clock/mvebu-core-clock.txt | 1 +
.../bindings/pinctrl/marvell,orion-pinctrl.txt | 4 +-
drivers/clk/mvebu/orion.c | 70 ++++++++++++++++++++++
drivers/pinctrl/mvebu/pinctrl-orion.c | 23 +++----
4 files changed, 86 insertions(+), 12 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Gregory CLEMENT @ 2016-09-14 15:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for soc for mvebu for v4.9.
Gregory
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-soc-4.9-1
for you to fetch changes up to a7f9f5baf306ff5422e6ab143c0af5dd6b5ed1a9:
ARM: orion5x: Remove old non-DT-based WNR854T support (2016-09-14 16:57:26 +0200)
----------------------------------------------------------------
mvebu soc for 4.9 (part 1)
- irq cleanup for old mvebu SoC
- Convert orion5x based SoC Netgear WNR854T to devicetree
----------------------------------------------------------------
Arnd Bergmann (4):
ARM: mv78xx0: simplify ethernet device creation
ARM: mvebu/orion: remove NO_IRQ check from device init
ARM: orion: simplify orion_ge00_switch_init
ARM: orion5x: remove extraneous NO_IRQ
Jamie Lentin (2):
ARM: orion5x: Add DT-based support for Netgear WNR854T
ARM: orion5x: Remove old non-DT-based WNR854T support
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/mvebu_v5_defconfig | 2 +-
arch/arm/configs/orion5x_defconfig | 2 +-
arch/arm/mach-mv78xx0/common.c | 9 +-
arch/arm/mach-orion5x/Kconfig | 4 +-
arch/arm/mach-orion5x/Makefile | 2 +-
arch/arm/mach-orion5x/board-wnr854t.c | 78 +++++++++++
arch/arm/mach-orion5x/common.c | 4 +-
arch/arm/mach-orion5x/common.h | 2 +-
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 4 +-
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 5 +-
arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c | 6 +-
arch/arm/mach-orion5x/wnr854t-setup.c | 185 ---------------------------
arch/arm/mach-orion5x/wrt350n-v2-setup.c | 4 +-
arch/arm/plat-orion/common.c | 85 +++++-------
arch/arm/plat-orion/include/plat/common.h | 10 +-
16 files changed, 133 insertions(+), 271 deletions(-)
create mode 100644 arch/arm/mach-orion5x/board-wnr854t.c
delete mode 100644 arch/arm/mach-orion5x/wnr854t-setup.c
^ permalink raw reply
* [GIT PULL] ARM: mediatek: dts64 updates for v4.9
From: Arnd Bergmann @ 2016-09-14 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <786a9070-5ea7-02d2-dce6-1f069f75ca18@gmail.com>
On Monday, September 12, 2016 5:51:03 PM CEST Matthias Brugger wrote:
> - add HDMI related nodes to mt8173
> - enable the HDMI output on mt8173-evb
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.9 (#2)
From: Gregory CLEMENT @ 2016-09-14 15:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the second pull request for dt64 for mvebu for v4.9.
This one is not related to the convert orion5x based SoC Netgear WNR854T
to devicetree, but it is just a small update on the device tree.
Gregory
The following changes since commit 98e45c1675a018e1121c1244985cf80b790fb6c4:
arm64: dts: marvell: describe the PIC and PMU on Armada 7K/8K (2016-08-26 10:57:20 +0200)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.9-2
for you to fetch changes up to 93970e67bdaec174ba8dad93e5ebb55be98f8d61:
arm64: dts: marvell: enable MSI for PCIe on Armada 7K/8K (2016-09-14 16:21:09 +0200)
----------------------------------------------------------------
mvebu dt64 for 4.9 (part 2)
- enable MSI for PCIe on Armada 7K/8K
----------------------------------------------------------------
Thomas Petazzoni (1):
arm64: dts: marvell: enable MSI for PCIe on Armada 7K/8K
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 3 +++
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 3 +++
2 files changed, 6 insertions(+)
^ permalink raw reply
* [PATCH 1/6] PCI: xilinx: Keep both legacy and MSI interrupt references.
From: Bharat Kumar Gogada @ 2016-09-14 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913155641.GB4138@localhost>
On Thu, Sep 01, 2016 at 03:44:41PM +0530, Bharat Kumar Gogada wrote:
> When built with MSI support the legacy domain reference is being
> overwritten with MSI.
> Instead creating two separate domains for MSI and legacy interrupts.
>
> Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
Applied all these (except [5/6]) with Michal's ack to pci/host-xilinx for v4.9, thanks!
I already applied Po Liu's patch ("PCI: xilinx: Relax device number checking to allow SR-IOV") to pci/virtualization. This is identical to [5/6], so I dropped [5/6] to avoid a conflict.
Thanks Bjorn.
Some how I couldn't find Po Liu's patch, can you provide git link of patch that was applied.
Hope it wouldn't take much time of you.
Thanks & Regards,
Bharat
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt for v4.9 (#2)
From: Gregory CLEMENT @ 2016-09-14 15:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the second pull request for dt for mvebu for v4.9.
As seen yesterday I submit the late pull requests today. It is mainly
for the convert of the Netgear WNR854T to devicetree. I needed to split
the original commits to apply them on the usual branches we use.
Gregory
The following changes since commit a305cc2fce217510dd255356d783e2c01cbc3a8f:
ARM: dts: mvebu: fix reference to a390 spi controller (2016-08-29 11:26:11 +0200)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.9-2
for you to fetch changes up to d30363364811e956816cb586936269ecb9a30299:
ARM: dts: orion5x: Configure WNR854T ethernet PHY LEDs (2016-09-14 17:00:26 +0200)
----------------------------------------------------------------
mvebu dt for 4.9 (part 2)
- convert orion5x based SoC Netgear WNR854T to devicetree
- remove obsolete orion-gpio binding description
----------------------------------------------------------------
Baruch Siach (1):
dt-binding: mrvl-gpio: remove orion-gpio description
Jamie Lentin (5):
ARM: dts: orion5x: Add required properties for orion-wdt to DT node
dt-bindings: arm: add DT binding for Marvell Orion5x SoC family
ARM: dts: arm: orion5x: Add DT include for mv88f5181
ARM: dts: orion5x: Add description for Netgear WNR854T
ARM: dts: orion5x: Configure WNR854T ethernet PHY LEDs
.../bindings/arm/marvell/marvell,orion5x.txt | 25 ++
.../devicetree/bindings/gpio/mrvl-gpio.txt | 23 --
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/orion5x-mv88f5181.dtsi | 49 ++++
arch/arm/boot/dts/orion5x-netgear-wnr854t.dts | 251 +++++++++++++++++++++
arch/arm/boot/dts/orion5x.dtsi | 3 +-
6 files changed, 328 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
create mode 100644 arch/arm/boot/dts/orion5x-mv88f5181.dtsi
create mode 100644 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
^ permalink raw reply
* [GIT PULL 4/5] Freescale arm64 device tree updates for 4.9
From: Arnd Bergmann @ 2016-09-14 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473670948-4265-4-git-send-email-shawnguo@kernel.org>
On Monday, September 12, 2016 5:02:27 PM CEST Shawn Guo wrote:
> i.MX arm64 device tree changes for 4.9:
> - Add property dma-coherent for ls2080a PCI device to save software
> cache maintenance.
> - Update serial aliases and use stdout-path to sepecify console for
> ls2080a and ls1043a boards.
> - Add DDR memory controller device node for ls2080a and ls1043a SoCs.
>
Pulled into next/dt64, thanks!
The "dma-coherent" change sounds like a bugfix, should that be backported
to stable kernels? Usually if you lack that property on a device that
is actually coherent, you can get silent data corruption by treating it as
non-coherent.
Arnd
^ permalink raw reply
* [GIT PULL 4/4] arm64: tegra: Device tree changes for v4.9-rc1
From: Arnd Bergmann @ 2016-09-14 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909152032.9550-4-thierry.reding@gmail.com>
On Friday, September 9, 2016 5:20:32 PM CEST Thierry Reding wrote:
> arm64: tegra: Device tree changes for v4.9-rc1
>
> Add a couple of devices (AGIC, ADMA) on Tegra210 and enable them on
> Smaug. Also enable DPAUX on Smaug to allow the I2C bus that shares pads
> with the DPAUX to be used to access various audio devices. Furthermore,
> enable the XUSB controller on Smaug for USB 3.0 support.
>
> Finally, select PM_GENERIC_DOMAINS for 64-bit Tegra devices to make sure
> devices are probed only after their power partitions have been enabled.
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 3/3] Rockchip dts64 changes for 4.9
From: Arnd Bergmann @ 2016-09-14 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5210110.HMx7zZ3pZH@phil>
On Thursday, September 8, 2016 4:11:52 PM CEST Heiko Stuebner wrote:
> 64bit Rockchip devicetree changes containing support for the recently
> added firmware reboot-flag support, one new board the Tronsmart Orion
> based on the rk3368 and a large number of newly supported peripherals
> for the rk3399 (type-c phy, usb2 phy, pcie controller and pcie phy,
> gmac, arm-pmu using ppi partitioning, efuse, saradc) as well as some
> smaller housekeeping and non-critical fixes.
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [PATCH v4 07/10] ARM: Introduce MPIDR_LEVEL_SHIFT macro
From: Vladimir Murzin @ 2016-09-14 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D7D88F.805@arm.com>
On 13/09/16 11:44, Marc Zyngier wrote:
> On 13/09/16 11:32, Vladimir Murzin wrote:
>> On 13/09/16 11:12, Marc Zyngier wrote:
>>> On 13/09/16 10:04, Vladimir Murzin wrote:
>>>> On 13/09/16 09:38, Christoffer Dall wrote:
>>>>> On Mon, Sep 12, 2016 at 03:49:21PM +0100, Vladimir Murzin wrote:
>>>>>> vgic-v3 driver uses architecture specific MPIDR_LEVEL_SHIFT macro to
>>>>>> encode the affinity in a form compatible with ICC_SGI* registers.
>>>>>> Unfortunately, that macro is missing on ARM, so let's add it.
>>>>>>
>>>>>> Cc: Russell King <rmk+kernel@armlinux.org.uk>
>>>>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>>>>> ---
>>>>>> arch/arm/include/asm/cputype.h | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
>>>>>> index 1ee94c7..e2d94c1 100644
>>>>>> --- a/arch/arm/include/asm/cputype.h
>>>>>> +++ b/arch/arm/include/asm/cputype.h
>>>>>> @@ -55,6 +55,7 @@
>>>>>>
>>>>>> #define MPIDR_LEVEL_BITS 8
>>>>>> #define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
>>>>>> +#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * level)
>>>>>>
>>>>>
>>>>> I'm not sure I follow the correctness of this completely.
>>>>>
>>>>> This is called from vgic_v3_dispatch_sgi, which takes a u64 value, which
>>>>> may have something in the Aff3 field, which we now shift left 24 bits,
>>>>> but that is not the Aff3 field of AArch32's MPIDR.
>>>>>
>>>>> What is the rationale for this making sense again?
>>>>
>>>> IIUC, in such case we construct mpidr which won't match in match_mpidr()
>>>> with the value we get from kvm_vcpu_get_mpidr_aff() and no SGI will be
>>>> sent to the guest.
>>>>
>>>> Since we get that u64 value from the guest, I'd think it is something
>>>> wrong is going on in the guest in case Aff3 is non-zero; however, we can
>>>> hide it by zeroing out SGI Aff3 bits in access_gic_sgi().
>>>
>>> I don't think zeroing Aff3 is the right move, as the spec doesn't say
>>> that Aff3 should be ignored in a write to ICC_SGI1R. On the other hand,
>>> the spec says (in the context of the target list): "If a bit is 1 and
>>> the bit does not correspond to a valid target PE, the bit must be
>>> ignored by the Distributor".
>>>
>>> This makes me think that, unless ICC_SGI1R.IMR is set, we should simply
>>> ignore that SGI because there is no way we can actually deliver it.
>>>
>>> Could you cook a small patch that would go on top of this series?
>>
>> I assume you've meant ICC_SGI1R.IRM, aka broadcast. In this case,
>
> Yes, sorry.
>
>> vgic_v3_dispatch_sgi() seems already matches the logic you've described:
>>
>> - if IRM == 1, send to everyone except self without check for mpidr
>> - if IRM == 0, send to target iff matched to a valid mpidr
>>
>> Am I missing something?
>
> Not much. My only ask was that if Aff3 was set, we could take the
> shortcut of not calling vgic_v3_dispatch_sgi() at all and return
> immediately. But as you said, we already deal with the case of invalid
> MPIDRs.
>
Anything I can do to make this patch better?
Cheers
Vladimir
> Thanks,
>
> M.
>
^ permalink raw reply
* [GIT PULL 4/4] Broadcom devicetree-arm64 changes for 4.9
From: Arnd Bergmann @ 2016-09-14 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473213558-11782-4-git-send-email-f.fainelli@gmail.com>
On Tuesday, September 6, 2016 6:59:18 PM CEST Florian Fainelli wrote:
> This pull request contains Broadcom ARM64-based SoC Device Tree changes for
> v4.9, please pull the folllowing:
>
> - Dhanajay adds the PWM Device Tree nodes to the Northstar 2 DTS files
>
Pulled into next/dt64, thanks!
I did the pull requests for next/dt yesterday but evidently missed yours.
Don't worry about it, I've already looked at it and it's fine. We'll
pick it up in the next few days along with your other two pull requests.
Arnd
^ permalink raw reply
* [PATCH v4 01/10] arm64: KVM: Use static keys for selecting the GIC backend
From: Vladimir Murzin @ 2016-09-14 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913092234.GA30056@cbox>
On 13/09/16 10:22, Christoffer Dall wrote:
> On Tue, Sep 13, 2016 at 10:11:10AM +0100, Marc Zyngier wrote:
>> On 13/09/16 09:20, Christoffer Dall wrote:
>>> On Mon, Sep 12, 2016 at 03:49:15PM +0100, Vladimir Murzin wrote:
>>>> Currently GIC backend is selected via alternative framework and this
>>>> is fine. We are going to introduce vgic-v3 to 32-bit world and there
>>>> we don't have patching framework in hand, so we can either check
>>>> support for GICv3 every time we need to choose which backend to use or
>>>> try to optimise it by using static keys. The later looks quite
>>>> promising because we can share logic involved in selecting GIC backend
>>>> between architectures if both uses static keys.
>>>>
>>>> This patch moves arm64 from alternative to static keys framework for
>>>> selecting GIC backend. For that we embed static key into vgic_global
>>>> and enable the key during vgic initialisation based on what has
>>>> already been exposed by the host GIC driver.
>>>>
>>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>>> ---
>>>> arch/arm64/kvm/hyp/switch.c | 21 +++++++++++----------
>>>> include/kvm/arm_vgic.h | 4 ++++
>>>> virt/kvm/arm/vgic/vgic-init.c | 4 ++++
>>>> virt/kvm/arm/vgic/vgic.c | 2 +-
>>>> 4 files changed, 20 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>>>> index 5a84b45..d5c4cc5 100644
>>>> --- a/arch/arm64/kvm/hyp/switch.c
>>>> +++ b/arch/arm64/kvm/hyp/switch.c
>>>> @@ -16,6 +16,8 @@
>>>> */
>>>>
>>>> #include <linux/types.h>
>>>> +#include <linux/jump_label.h>
>>>> +
>>>> #include <asm/kvm_asm.h>
>>>> #include <asm/kvm_hyp.h>
>>>>
>>>> @@ -126,17 +128,13 @@ static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
>>>> write_sysreg(0, vttbr_el2);
>>>> }
>>>>
>>>> -static hyp_alternate_select(__vgic_call_save_state,
>>>> - __vgic_v2_save_state, __vgic_v3_save_state,
>>>> - ARM64_HAS_SYSREG_GIC_CPUIF);
>>>> -
>>>> -static hyp_alternate_select(__vgic_call_restore_state,
>>>> - __vgic_v2_restore_state, __vgic_v3_restore_state,
>>>> - ARM64_HAS_SYSREG_GIC_CPUIF);
>>>> -
>>>> static void __hyp_text __vgic_save_state(struct kvm_vcpu *vcpu)
>>>> {
>>>> - __vgic_call_save_state()(vcpu);
>>>> + if (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
>>>
>>> It's a bit weird that we use _unlikely for GICv3 (at least if/when GICv3
>>> hardware becomes mainstream), but as we don't have another primitive for
>>> the 'default disabled' case, I suppose that's the best we can do.
>>
>> We could always revert the "likelihood" of that test once GICv3 has
>> conquered the world. Or start patching the 32bit kernel like we do for
>> 64bit...
>>
>>>
>>>> + __vgic_v3_save_state(vcpu);
>>>> + else
>>>> + __vgic_v2_save_state(vcpu);
>>>> +
>>>> write_sysreg(read_sysreg(hcr_el2) & ~HCR_INT_OVERRIDE, hcr_el2);
>>>> }
>>>>
>>>> @@ -149,7 +147,10 @@ static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
>>>> val |= vcpu->arch.irq_lines;
>>>> write_sysreg(val, hcr_el2);
>>>>
>>>> - __vgic_call_restore_state()(vcpu);
>>>> + if (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
>>>> + __vgic_v3_restore_state(vcpu);
>>>> + else
>>>> + __vgic_v2_restore_state(vcpu);
>>>> }
>>>>
>>>> static bool __hyp_text __true_value(void)
>>>> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>>>> index 19b698e..994665a 100644
>>>> --- a/include/kvm/arm_vgic.h
>>>> +++ b/include/kvm/arm_vgic.h
>>>> @@ -23,6 +23,7 @@
>>>> #include <linux/types.h>
>>>> #include <kvm/iodev.h>
>>>> #include <linux/list.h>
>>>> +#include <linux/jump_label.h>
>>>>
>>>> #define VGIC_V3_MAX_CPUS 255
>>>> #define VGIC_V2_MAX_CPUS 8
>>>> @@ -63,6 +64,9 @@ struct vgic_global {
>>>>
>>>> /* Only needed for the legacy KVM_CREATE_IRQCHIP */
>>>> bool can_emulate_gicv2;
>>>> +
>>>> + /* GIC system register CPU interface */
>>>> + struct static_key_false gicv3_cpuif;
>>>
>>> Documentation/static-keys.txt says that we are not supposed to use
>>> struct static_key_false directly. This will obviously work quite
>>> nicely, but we could consider adding a pair of
>>> DECLARE_STATIC_KEY_TRUE/FALSE macros that don't have the assignments,
>>> but obviously this will need an ack from other maintainers.
>>>
>>> Thoughts?
>>
>> Grepping through the tree shows that we're not the only abusers of this
>> (dynamic debug is far worse!). Happy to write the additional macros and
>> submit them if nobody beats me to it.
>>
>>>
>>>
>>>> };
>>>>
>>>> extern struct vgic_global kvm_vgic_global_state;
>>>> diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
>>>> index 83777c1..14d6718 100644
>>>> --- a/virt/kvm/arm/vgic/vgic-init.c
>>>> +++ b/virt/kvm/arm/vgic/vgic-init.c
>>>> @@ -405,6 +405,10 @@ int kvm_vgic_hyp_init(void)
>>>> break;
>>>> case GIC_V3:
>>>> ret = vgic_v3_probe(gic_kvm_info);
>>>> + if (!ret) {
>>>> + static_branch_enable(&kvm_vgic_global_state.gicv3_cpuif);
>>>> + kvm_info("GIC system register CPU interface\n");
>>>
>>> nit: add enabled to the info message?
>>>
>>>> + }
>>>> break;
>>>> default:
>>>> ret = -ENODEV;
>>>> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
>>>> index e83b7fe..8a529a7 100644
>>>> --- a/virt/kvm/arm/vgic/vgic.c
>>>> +++ b/virt/kvm/arm/vgic/vgic.c
>>>> @@ -29,7 +29,7 @@
>>>> #define DEBUG_SPINLOCK_BUG_ON(p)
>>>> #endif
>>>>
>>>> -struct vgic_global __section(.hyp.text) kvm_vgic_global_state;
>>>> +struct vgic_global __section(.hyp.text) kvm_vgic_global_state = {.gicv3_cpuif = STATIC_KEY_FALSE_INIT,};
>>>>
>>>> /*
>>>> * Locking order is always:
>>>> --
>>>> 1.7.9.5
>>>>
>>>
>>> Overall this looks really nice, as long as we're clear on the static
>>> keys stuff.
>>
>> Indeed, we should get this sorted, though I'm not sure this should be a
>> blocker for this code.
>>
> Agreed, let's ship it!
To make it clear, should I respin with "enabled" into the info message
and macros for static keys?
Cheers
Vladimir
> -Christoffer
>
>
^ 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