* Applied "regulator: arizona: Split KConfig options for LDO1 and MICSUPP regulators" to the regulator tree
From: Mark Brown @ 2017-04-25 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-3-git-send-email-rf@opensource.wolfsonmicro.com>
The patch
regulator: arizona: Split KConfig options for LDO1 and MICSUPP regulators
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7e6425968bf742b9772aa5bae1250158c9312e31 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Date: Tue, 18 Apr 2017 11:43:48 +0100
Subject: [PATCH] regulator: arizona: Split KConfig options for LDO1 and
MICSUPP regulators
The CS47L24 Arizona codec and most Madera codecs do not have a LDO1
regulator. Split the LDO1 and MICSUPP regulators into separate KConfig
options so the LDO1 is only built into the kernel if needed.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/Kconfig | 14 +++++++++++---
drivers/regulator/Makefile | 3 ++-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index be06eb29c681..c026b09c479c 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -125,12 +125,20 @@ config REGULATOR_AB8500
This driver supports the regulators found on the ST-Ericsson mixed
signal AB8500 PMIC
-config REGULATOR_ARIZONA
- tristate "Wolfson Arizona class devices"
+config REGULATOR_ARIZONA_LDO1
+ tristate "Wolfson Arizona class devices LDO1"
depends on MFD_ARIZONA
depends on SND_SOC
help
- Support for the regulators found on Wolfson Arizona class
+ Support for the LDO1 regulators found on Wolfson Arizona class
+ devices.
+
+config REGULATOR_ARIZONA_MICSUPP
+ tristate "Wolfson Arizona class devices MICSUPP"
+ depends on MFD_ARIZONA
+ depends on SND_SOC
+ help
+ Support for the MICSUPP regulators found on Wolfson Arizona class
devices.
config REGULATOR_AS3711
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index ef7725e2592a..313a7ca97b4d 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -19,7 +19,8 @@ obj-$(CONFIG_REGULATOR_ACT8865) += act8865-regulator.o
obj-$(CONFIG_REGULATOR_ACT8945A) += act8945a-regulator.o
obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o
obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o
-obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o arizona-ldo1.o
+obj-$(CONFIG_REGULATOR_ARIZONA_LDO1) += arizona-ldo1.o
+obj-$(CONFIG_REGULATOR_ARIZONA_MICSUPP) += arizona-micsupp.o
obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
--
2.11.0
^ permalink raw reply related
* Applied "regulator: arizona-micsupp: Move pdata into a separate structure" to the regulator tree
From: Mark Brown @ 2017-04-25 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-4-git-send-email-rf@opensource.wolfsonmicro.com>
The patch
regulator: arizona-micsupp: Move pdata into a separate structure
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 22161f3eb65dc29434325736c4d780908fe3bf6a Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Date: Tue, 18 Apr 2017 11:43:49 +0100
Subject: [PATCH] regulator: arizona-micsupp: Move pdata into a separate
structure
In preparation for sharing this driver with Madera, move the pdata
for the micsupp regulator out of struct arizona_pdata into a dedicated
pdata struct for this driver. As a result the code in
arizona_micsupp_of_get_pdata() can be made independent of struct arizona.
This patch also updates the definition of struct arizona_pdata and
the use of this pdata in mach-crag6410-module.c
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
MAINTAINERS | 1 +
drivers/regulator/arizona-micsupp.c | 21 +++++++++++----------
include/linux/mfd/arizona/pdata.h | 3 ++-
include/linux/regulator/arizona-micsupp.h | 21 +++++++++++++++++++++
4 files changed, 35 insertions(+), 11 deletions(-)
create mode 100644 include/linux/regulator/arizona-micsupp.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c35e0cea7831..6ed8ef18e7b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13623,6 +13623,7 @@ F: include/linux/mfd/arizona/
F: include/linux/mfd/wm831x/
F: include/linux/mfd/wm8350/
F: include/linux/mfd/wm8400*
+F: include/linux/regulator/arizona*
F: include/linux/wm97xx.h
F: include/sound/wm????.h
F: sound/soc/codecs/arizona.?
diff --git a/drivers/regulator/arizona-micsupp.c b/drivers/regulator/arizona-micsupp.c
index 5e38861e71d8..5f8b5a713311 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -30,6 +30,8 @@
#include <linux/mfd/arizona/pdata.h>
#include <linux/mfd/arizona/registers.h>
+#include <linux/regulator/arizona-micsupp.h>
+
struct arizona_micsupp {
struct regulator_dev *regulator;
struct arizona *arizona;
@@ -199,28 +201,26 @@ static const struct regulator_init_data arizona_micsupp_ext_default = {
.num_consumer_supplies = 1,
};
-static int arizona_micsupp_of_get_pdata(struct device *dev,
- struct arizona *arizona,
+static int arizona_micsupp_of_get_pdata(struct arizona_micsupp_pdata *pdata,
struct regulator_config *config,
const struct regulator_desc *desc)
{
- struct arizona_pdata *pdata = &arizona->pdata;
struct arizona_micsupp *micsupp = config->driver_data;
struct device_node *np;
struct regulator_init_data *init_data;
- np = of_get_child_by_name(arizona->dev->of_node, "micvdd");
+ np = of_get_child_by_name(config->dev->of_node, "micvdd");
if (np) {
config->of_node = np;
- init_data = of_get_regulator_init_data(dev, np, desc);
+ init_data = of_get_regulator_init_data(config->dev, np, desc);
if (init_data) {
init_data->consumer_supplies = &micsupp->supply;
init_data->num_consumer_supplies = 1;
- pdata->micvdd = init_data;
+ pdata->init_data = init_data;
}
}
@@ -232,6 +232,7 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
const struct regulator_desc *desc;
struct regulator_config config = { };
+ struct arizona_micsupp_pdata *pdata = &arizona->pdata.micvdd;
struct arizona_micsupp *micsupp;
int ret;
@@ -269,15 +270,15 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_micsupp_of_get_pdata(&pdev->dev, arizona,
- &config, desc);
+ ret = arizona_micsupp_of_get_pdata(pdata, &config,
+ desc);
if (ret < 0)
return ret;
}
}
- if (arizona->pdata.micvdd)
- config.init_data = arizona->pdata.micvdd;
+ if (pdata->init_data)
+ config.init_data = pdata->init_data;
else
config.init_data = &micsupp->init_data;
diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h
index 64faeeff698c..43e875f9850c 100644
--- a/include/linux/mfd/arizona/pdata.h
+++ b/include/linux/mfd/arizona/pdata.h
@@ -12,6 +12,7 @@
#define _ARIZONA_PDATA_H
#include <dt-bindings/mfd/arizona.h>
+#include <linux/regulator/arizona-micsupp.h>
#define ARIZONA_GPN_DIR_MASK 0x8000 /* GPN_DIR */
#define ARIZONA_GPN_DIR_SHIFT 15 /* GPN_DIR */
@@ -79,7 +80,7 @@ struct arizona_pdata {
int ldoena; /** GPIO controlling LODENA, if any */
/** Regulator configuration for MICVDD */
- struct regulator_init_data *micvdd;
+ struct arizona_micsupp_pdata micvdd;
/** Regulator configuration for LDO1 */
struct regulator_init_data *ldo1;
diff --git a/include/linux/regulator/arizona-micsupp.h b/include/linux/regulator/arizona-micsupp.h
new file mode 100644
index 000000000000..616842619c00
--- /dev/null
+++ b/include/linux/regulator/arizona-micsupp.h
@@ -0,0 +1,21 @@
+/*
+ * Platform data for Arizona micsupp regulator
+ *
+ * Copyright 2017 Cirrus Logic
+ *
+ * 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.
+ */
+
+#ifndef ARIZONA_MICSUPP_H
+#define ARIZONA_MICSUPP_H
+
+struct regulator_init_data;
+
+struct arizona_micsupp_pdata {
+ /** Regulator configuration for micsupp */
+ const struct regulator_init_data *init_data;
+};
+
+#endif
--
2.11.0
^ permalink raw reply related
* Applied "regulator: arizona-micsupp: Make arizona_micsupp independent of struct arizona" to the regulator tree
From: Mark Brown @ 2017-04-25 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-5-git-send-email-rf@opensource.wolfsonmicro.com>
The patch
regulator: arizona-micsupp: Make arizona_micsupp independent of struct arizona
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From e165983e5102c953d68bd935048e95567564e438 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Date: Tue, 18 Apr 2017 11:43:50 +0100
Subject: [PATCH] regulator: arizona-micsupp: Make arizona_micsupp independent
of struct arizona
In preparation for supporting Madera codecs, remove the dependency on
struct arizona in the regulator callbacks and struct arizona_micsupp.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-micsupp.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c b/drivers/regulator/arizona-micsupp.c
index 5f8b5a713311..db4fecf228b7 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -34,7 +34,10 @@
struct arizona_micsupp {
struct regulator_dev *regulator;
- struct arizona *arizona;
+ struct regmap *regmap;
+ struct snd_soc_dapm_context **dapm;
+ unsigned int enable_reg;
+ struct device *dev;
struct regulator_consumer_supply supply;
struct regulator_init_data init_data;
@@ -46,21 +49,22 @@ static void arizona_micsupp_check_cp(struct work_struct *work)
{
struct arizona_micsupp *micsupp =
container_of(work, struct arizona_micsupp, check_cp_work);
- struct snd_soc_dapm_context *dapm = micsupp->arizona->dapm;
- struct snd_soc_component *component = snd_soc_dapm_to_component(dapm);
- struct arizona *arizona = micsupp->arizona;
- struct regmap *regmap = arizona->regmap;
- unsigned int reg;
+ struct snd_soc_dapm_context *dapm = *micsupp->dapm;
+ struct snd_soc_component *component;
+ unsigned int val;
int ret;
- ret = regmap_read(regmap, ARIZONA_MIC_CHARGE_PUMP_1, ®);
+ ret = regmap_read(micsupp->regmap, micsupp->enable_reg, &val);
if (ret != 0) {
- dev_err(arizona->dev, "Failed to read CP state: %d\n", ret);
+ dev_err(micsupp->dev,
+ "Failed to read CP state: %d\n", ret);
return;
}
if (dapm) {
- if ((reg & (ARIZONA_CPMIC_ENA | ARIZONA_CPMIC_BYPASS)) ==
+ component = snd_soc_dapm_to_component(dapm);
+
+ if ((val & (ARIZONA_CPMIC_ENA | ARIZONA_CPMIC_BYPASS)) ==
ARIZONA_CPMIC_ENA)
snd_soc_component_force_enable_pin(component,
"MICSUPP");
@@ -240,7 +244,9 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
if (!micsupp)
return -ENOMEM;
- micsupp->arizona = arizona;
+ micsupp->regmap = arizona->regmap;
+ micsupp->dapm = &arizona->dapm;
+ micsupp->dev = arizona->dev;
INIT_WORK(&micsupp->check_cp_work, arizona_micsupp_check_cp);
/*
@@ -263,6 +269,7 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
micsupp->init_data.consumer_supplies = &micsupp->supply;
micsupp->supply.supply = "MICVDD";
micsupp->supply.dev_name = dev_name(arizona->dev);
+ micsupp->enable_reg = desc->enable_reg;
config.dev = arizona->dev;
config.driver_data = micsupp;
--
2.11.0
^ permalink raw reply related
* Applied "regulator: arizona-micsupp: Factor out generic initialization" to the regulator tree
From: Mark Brown @ 2017-04-25 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-6-git-send-email-rf@opensource.wolfsonmicro.com>
The patch
regulator: arizona-micsupp: Factor out generic initialization
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7d8d14b51921cbfe082a796e55c22d0c1dd8fc26 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Date: Tue, 18 Apr 2017 11:43:51 +0100
Subject: [PATCH] regulator: arizona-micsupp: Factor out generic initialization
In preparation for sharing this driver with Madera codecs, factor out
the parts of initialization that aren't dependent on struct arizona.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-micsupp.c | 82 +++++++++++++++++++++----------------
1 file changed, 46 insertions(+), 36 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c b/drivers/regulator/arizona-micsupp.c
index db4fecf228b7..120de94caf02 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -231,52 +231,27 @@ static int arizona_micsupp_of_get_pdata(struct arizona_micsupp_pdata *pdata,
return 0;
}
-static int arizona_micsupp_probe(struct platform_device *pdev)
+static int arizona_micsupp_common_init(struct platform_device *pdev,
+ struct arizona_micsupp *micsupp,
+ const struct regulator_desc *desc,
+ struct arizona_micsupp_pdata *pdata)
{
- struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
- const struct regulator_desc *desc;
struct regulator_config config = { };
- struct arizona_micsupp_pdata *pdata = &arizona->pdata.micvdd;
- struct arizona_micsupp *micsupp;
int ret;
- micsupp = devm_kzalloc(&pdev->dev, sizeof(*micsupp), GFP_KERNEL);
- if (!micsupp)
- return -ENOMEM;
-
- micsupp->regmap = arizona->regmap;
- micsupp->dapm = &arizona->dapm;
- micsupp->dev = arizona->dev;
INIT_WORK(&micsupp->check_cp_work, arizona_micsupp_check_cp);
- /*
- * Since the chip usually supplies itself we provide some
- * default init_data for it. This will be overridden with
- * platform data if provided.
- */
- switch (arizona->type) {
- case WM5110:
- case WM8280:
- desc = &arizona_micsupp_ext;
- micsupp->init_data = arizona_micsupp_ext_default;
- break;
- default:
- desc = &arizona_micsupp;
- micsupp->init_data = arizona_micsupp_default;
- break;
- }
-
micsupp->init_data.consumer_supplies = &micsupp->supply;
micsupp->supply.supply = "MICVDD";
- micsupp->supply.dev_name = dev_name(arizona->dev);
+ micsupp->supply.dev_name = dev_name(micsupp->dev);
micsupp->enable_reg = desc->enable_reg;
- config.dev = arizona->dev;
+ config.dev = micsupp->dev;
config.driver_data = micsupp;
- config.regmap = arizona->regmap;
+ config.regmap = micsupp->regmap;
if (IS_ENABLED(CONFIG_OF)) {
- if (!dev_get_platdata(arizona->dev)) {
+ if (!dev_get_platdata(micsupp->dev)) {
ret = arizona_micsupp_of_get_pdata(pdata, &config,
desc);
if (ret < 0)
@@ -289,8 +264,8 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
else
config.init_data = &micsupp->init_data;
- /* Default to regulated mode until the API supports bypass */
- regmap_update_bits(arizona->regmap, ARIZONA_MIC_CHARGE_PUMP_1,
+ /* Default to regulated mode */
+ regmap_update_bits(micsupp->regmap, micsupp->enable_reg,
ARIZONA_CPMIC_BYPASS, 0);
micsupp->regulator = devm_regulator_register(&pdev->dev,
@@ -301,7 +276,7 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
if (IS_ERR(micsupp->regulator)) {
ret = PTR_ERR(micsupp->regulator);
- dev_err(arizona->dev, "Failed to register mic supply: %d\n",
+ dev_err(micsupp->dev, "Failed to register mic supply: %d\n",
ret);
return ret;
}
@@ -311,6 +286,41 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
return 0;
}
+static int arizona_micsupp_probe(struct platform_device *pdev)
+{
+ struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
+ const struct regulator_desc *desc;
+ struct arizona_micsupp *micsupp;
+
+ micsupp = devm_kzalloc(&pdev->dev, sizeof(*micsupp), GFP_KERNEL);
+ if (!micsupp)
+ return -ENOMEM;
+
+ micsupp->regmap = arizona->regmap;
+ micsupp->dapm = &arizona->dapm;
+ micsupp->dev = arizona->dev;
+
+ /*
+ * Since the chip usually supplies itself we provide some
+ * default init_data for it. This will be overridden with
+ * platform data if provided.
+ */
+ switch (arizona->type) {
+ case WM5110:
+ case WM8280:
+ desc = &arizona_micsupp_ext;
+ micsupp->init_data = arizona_micsupp_ext_default;
+ break;
+ default:
+ desc = &arizona_micsupp;
+ micsupp->init_data = arizona_micsupp_default;
+ break;
+ }
+
+ return arizona_micsupp_common_init(pdev, micsupp, desc,
+ &arizona->pdata.micvdd);
+}
+
static struct platform_driver arizona_micsupp_driver = {
.probe = arizona_micsupp_probe,
.driver = {
--
2.11.0
^ permalink raw reply related
* Applied "regulator: arizona-ldo1: Move pdata into a separate structure" to the regulator tree
From: Mark Brown @ 2017-04-25 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-7-git-send-email-rf@opensource.wolfsonmicro.com>
The patch
regulator: arizona-ldo1: Move pdata into a separate structure
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From aaa84e6a0399df374634c42590e644a698fcc3ff Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Date: Tue, 18 Apr 2017 11:43:52 +0100
Subject: [PATCH] regulator: arizona-ldo1: Move pdata into a separate structure
In preparation for sharing this driver with Madera, move the pdata
for the LDO1 regulator out of struct arizona_pdata into a dedicated
pdata struct for this driver. As a result the code in
arizona_ldo1_of_get_pdata() can be made independent of struct arizona.
This patch also updates the definition of struct arizona_pdata and
the use of this pdata in mach-crag6410-module.c
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm/mach-s3c64xx/mach-crag6410-module.c | 8 ++++--
drivers/regulator/arizona-ldo1.c | 39 +++++++++++++++-------------
include/linux/mfd/arizona/pdata.h | 4 +--
include/linux/regulator/arizona-ldo1.h | 24 +++++++++++++++++
4 files changed, 53 insertions(+), 22 deletions(-)
create mode 100644 include/linux/regulator/arizona-ldo1.h
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410-module.c b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
index ccc3ab8d58e7..ea5f2169c850 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
@@ -209,7 +209,9 @@ static const struct i2c_board_info wm1277_devs[] = {
};
static struct arizona_pdata wm5102_reva_pdata = {
- .ldoena = S3C64XX_GPN(7),
+ .ldo1 = {
+ .ldoena = S3C64XX_GPN(7),
+ },
.gpio_base = CODEC_GPIO_BASE,
.irq_flags = IRQF_TRIGGER_HIGH,
.micd_pol_gpio = CODEC_GPIO_BASE + 4,
@@ -239,7 +241,9 @@ static struct spi_board_info wm5102_reva_spi_devs[] = {
};
static struct arizona_pdata wm5102_pdata = {
- .ldoena = S3C64XX_GPN(7),
+ .ldo1 = {
+ .ldoena = S3C64XX_GPN(7),
+ },
.gpio_base = CODEC_GPIO_BASE,
.irq_flags = IRQF_TRIGGER_HIGH,
.micd_pol_gpio = CODEC_GPIO_BASE + 2,
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index b726fa17f7b2..f5bc75ab85fa 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -25,6 +25,8 @@
#include <linux/gpio.h>
#include <linux/slab.h>
+#include <linux/regulator/arizona-ldo1.h>
+
#include <linux/mfd/arizona/core.h>
#include <linux/mfd/arizona/pdata.h>
#include <linux/mfd/arizona/registers.h>
@@ -186,20 +188,19 @@ static const struct regulator_init_data arizona_ldo1_wm5110 = {
.num_consumer_supplies = 1,
};
-static int arizona_ldo1_of_get_pdata(struct device *dev,
- struct arizona *arizona,
+static int arizona_ldo1_of_get_pdata(struct arizona_ldo1_pdata *pdata,
struct regulator_config *config,
- const struct regulator_desc *desc)
+ const struct regulator_desc *desc,
+ bool *external_dcvdd)
{
- struct arizona_pdata *pdata = &arizona->pdata;
struct arizona_ldo1 *ldo1 = config->driver_data;
- struct device_node *np = arizona->dev->of_node;
+ struct device_node *np = config->dev->of_node;
struct device_node *init_node, *dcvdd_node;
struct regulator_init_data *init_data;
pdata->ldoena = of_get_named_gpio(np, "wlf,ldoena", 0);
if (pdata->ldoena < 0) {
- dev_warn(arizona->dev,
+ dev_warn(config->dev,
"LDOENA GPIO property missing/malformed: %d\n",
pdata->ldoena);
pdata->ldoena = 0;
@@ -213,19 +214,19 @@ static int arizona_ldo1_of_get_pdata(struct device *dev,
if (init_node) {
config->of_node = init_node;
- init_data = of_get_regulator_init_data(dev, init_node, desc);
-
+ init_data = of_get_regulator_init_data(config->dev, init_node,
+ desc);
if (init_data) {
init_data->consumer_supplies = &ldo1->supply;
init_data->num_consumer_supplies = 1;
if (dcvdd_node && dcvdd_node != init_node)
- arizona->external_dcvdd = true;
+ *external_dcvdd = true;
- pdata->ldo1 = init_data;
+ pdata->init_data = init_data;
}
} else if (dcvdd_node) {
- arizona->external_dcvdd = true;
+ *external_dcvdd = true;
}
of_node_put(dcvdd_node);
@@ -239,10 +240,9 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
const struct regulator_desc *desc;
struct regulator_config config = { };
struct arizona_ldo1 *ldo1;
+ bool external_dcvdd = false;
int ret;
- arizona->external_dcvdd = false;
-
ldo1 = devm_kzalloc(&pdev->dev, sizeof(*ldo1), GFP_KERNEL);
if (!ldo1)
return -ENOMEM;
@@ -283,17 +283,18 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_ldo1_of_get_pdata(&pdev->dev, arizona,
- &config, desc);
+ ret = arizona_ldo1_of_get_pdata(&arizona->pdata.ldo1,
+ &config, desc,
+ &external_dcvdd);
if (ret < 0)
return ret;
}
}
- config.ena_gpio = arizona->pdata.ldoena;
+ config.ena_gpio = arizona->pdata.ldo1.ldoena;
- if (arizona->pdata.ldo1)
- config.init_data = arizona->pdata.ldo1;
+ if (arizona->pdata.ldo1.init_data)
+ config.init_data = arizona->pdata.ldo1.init_data;
else
config.init_data = &ldo1->init_data;
@@ -303,6 +304,8 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
*/
if (config.init_data->num_consumer_supplies == 0)
arizona->external_dcvdd = true;
+ else
+ arizona->external_dcvdd = external_dcvdd;
ldo1->regulator = devm_regulator_register(&pdev->dev, desc, &config);
diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h
index 43e875f9850c..bfeecf179895 100644
--- a/include/linux/mfd/arizona/pdata.h
+++ b/include/linux/mfd/arizona/pdata.h
@@ -12,6 +12,7 @@
#define _ARIZONA_PDATA_H
#include <dt-bindings/mfd/arizona.h>
+#include <linux/regulator/arizona-ldo1.h>
#include <linux/regulator/arizona-micsupp.h>
#define ARIZONA_GPN_DIR_MASK 0x8000 /* GPN_DIR */
@@ -77,13 +78,12 @@ struct arizona_micd_range {
struct arizona_pdata {
int reset; /** GPIO controlling /RESET, if any */
- int ldoena; /** GPIO controlling LODENA, if any */
/** Regulator configuration for MICVDD */
struct arizona_micsupp_pdata micvdd;
/** Regulator configuration for LDO1 */
- struct regulator_init_data *ldo1;
+ struct arizona_ldo1_pdata ldo1;
/** If a direct 32kHz clock is provided on an MCLK specify it here */
int clk32k_src;
diff --git a/include/linux/regulator/arizona-ldo1.h b/include/linux/regulator/arizona-ldo1.h
new file mode 100644
index 000000000000..c685f1277c63
--- /dev/null
+++ b/include/linux/regulator/arizona-ldo1.h
@@ -0,0 +1,24 @@
+/*
+ * Platform data for Arizona LDO1 regulator
+ *
+ * Copyright 2017 Cirrus Logic
+ *
+ * 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.
+ */
+
+#ifndef ARIZONA_LDO1_H
+#define ARIZONA_LDO1_H
+
+struct regulator_init_data;
+
+struct arizona_ldo1_pdata {
+ /** GPIO controlling LDOENA, if any */
+ int ldoena;
+
+ /** Regulator configuration for LDO1 */
+ const struct regulator_init_data *init_data;
+};
+
+#endif
--
2.11.0
^ permalink raw reply related
* Applied "regulator: arizona-ldo1: Make arizona_ldo1 independent of struct arizona" to the regulator tree
From: Mark Brown @ 2017-04-25 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-8-git-send-email-rf@opensource.wolfsonmicro.com>
The patch
regulator: arizona-ldo1: Make arizona_ldo1 independent of struct arizona
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 80a55f41aef4ee808f53f1a356491d7eaeefdd3c Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Date: Tue, 18 Apr 2017 11:43:53 +0100
Subject: [PATCH] regulator: arizona-ldo1: Make arizona_ldo1 independent of
struct arizona
In preparation for supporting Madera codecs, remove the dependency on
struct arizona in the regulator callbacks and struct arizona_ldo1.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-ldo1.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index f5bc75ab85fa..678f81fda22a 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -33,7 +33,7 @@
struct arizona_ldo1 {
struct regulator_dev *regulator;
- struct arizona *arizona;
+ struct regmap *regmap;
struct regulator_consumer_supply supply;
struct regulator_init_data init_data;
@@ -67,7 +67,7 @@ static int arizona_ldo1_hc_set_voltage_sel(struct regulator_dev *rdev,
unsigned sel)
{
struct arizona_ldo1 *ldo = rdev_get_drvdata(rdev);
- struct regmap *regmap = ldo->arizona->regmap;
+ struct regmap *regmap = ldo->regmap;
unsigned int val;
int ret;
@@ -93,7 +93,7 @@ static int arizona_ldo1_hc_set_voltage_sel(struct regulator_dev *rdev,
static int arizona_ldo1_hc_get_voltage_sel(struct regulator_dev *rdev)
{
struct arizona_ldo1 *ldo = rdev_get_drvdata(rdev);
- struct regmap *regmap = ldo->arizona->regmap;
+ struct regmap *regmap = ldo->regmap;
unsigned int val;
int ret;
@@ -247,7 +247,7 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
if (!ldo1)
return -ENOMEM;
- ldo1->arizona = arizona;
+ ldo1->regmap = arizona->regmap;
/*
* Since the chip usually supplies itself we provide some
--
2.11.0
^ permalink raw reply related
* Applied "regulator: arizona-ldo1: Factor out generic initialization" to the regulator tree
From: Mark Brown @ 2017-04-25 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-9-git-send-email-rf@opensource.wolfsonmicro.com>
The patch
regulator: arizona-ldo1: Factor out generic initialization
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From af367afafb5ba7ae26defd35e4ba42cfe157ef72 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Date: Tue, 18 Apr 2017 11:43:54 +0100
Subject: [PATCH] regulator: arizona-ldo1: Factor out generic initialization
In preparation for sharing this driver with Madera codecs, factor out
the parts of initialization that aren't dependent on struct arizona.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-ldo1.c | 114 ++++++++++++++++++++++-----------------
1 file changed, 66 insertions(+), 48 deletions(-)
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index 678f81fda22a..96fddfff5dc4 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -234,67 +234,40 @@ static int arizona_ldo1_of_get_pdata(struct arizona_ldo1_pdata *pdata,
return 0;
}
-static int arizona_ldo1_probe(struct platform_device *pdev)
+static int arizona_ldo1_common_init(struct platform_device *pdev,
+ struct arizona_ldo1 *ldo1,
+ const struct regulator_desc *desc,
+ struct arizona_ldo1_pdata *pdata,
+ bool *external_dcvdd)
{
- struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
- const struct regulator_desc *desc;
+ struct device *parent_dev = pdev->dev.parent;
struct regulator_config config = { };
- struct arizona_ldo1 *ldo1;
- bool external_dcvdd = false;
int ret;
- ldo1 = devm_kzalloc(&pdev->dev, sizeof(*ldo1), GFP_KERNEL);
- if (!ldo1)
- return -ENOMEM;
-
- ldo1->regmap = arizona->regmap;
-
- /*
- * Since the chip usually supplies itself we provide some
- * default init_data for it. This will be overridden with
- * platform data if provided.
- */
- switch (arizona->type) {
- case WM5102:
- case WM8997:
- case WM8998:
- case WM1814:
- desc = &arizona_ldo1_hc;
- ldo1->init_data = arizona_ldo1_dvfs;
- break;
- case WM5110:
- case WM8280:
- desc = &arizona_ldo1;
- ldo1->init_data = arizona_ldo1_wm5110;
- break;
- default:
- desc = &arizona_ldo1;
- ldo1->init_data = arizona_ldo1_default;
- break;
- }
+ *external_dcvdd = false;
- ldo1->init_data.consumer_supplies = &ldo1->supply;
ldo1->supply.supply = "DCVDD";
- ldo1->supply.dev_name = dev_name(arizona->dev);
+ ldo1->init_data.consumer_supplies = &ldo1->supply;
+ ldo1->supply.dev_name = dev_name(parent_dev);
- config.dev = arizona->dev;
+ config.dev = parent_dev;
config.driver_data = ldo1;
- config.regmap = arizona->regmap;
+ config.regmap = ldo1->regmap;
if (IS_ENABLED(CONFIG_OF)) {
- if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_ldo1_of_get_pdata(&arizona->pdata.ldo1,
+ if (!dev_get_platdata(parent_dev)) {
+ ret = arizona_ldo1_of_get_pdata(pdata,
&config, desc,
- &external_dcvdd);
+ external_dcvdd);
if (ret < 0)
return ret;
}
}
- config.ena_gpio = arizona->pdata.ldo1.ldoena;
+ config.ena_gpio = pdata->ldoena;
- if (arizona->pdata.ldo1.init_data)
- config.init_data = arizona->pdata.ldo1.init_data;
+ if (pdata->init_data)
+ config.init_data = pdata->init_data;
else
config.init_data = &ldo1->init_data;
@@ -303,9 +276,7 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
* consumers then DCVDD is supplied externally.
*/
if (config.init_data->num_consumer_supplies == 0)
- arizona->external_dcvdd = true;
- else
- arizona->external_dcvdd = external_dcvdd;
+ *external_dcvdd = true;
ldo1->regulator = devm_regulator_register(&pdev->dev, desc, &config);
@@ -313,7 +284,7 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
if (IS_ERR(ldo1->regulator)) {
ret = PTR_ERR(ldo1->regulator);
- dev_err(arizona->dev, "Failed to register LDO1 supply: %d\n",
+ dev_err(&pdev->dev, "Failed to register LDO1 supply: %d\n",
ret);
return ret;
}
@@ -323,6 +294,53 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
return 0;
}
+static int arizona_ldo1_probe(struct platform_device *pdev)
+{
+ struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
+ struct arizona_ldo1 *ldo1;
+ const struct regulator_desc *desc;
+ bool external_dcvdd;
+ int ret;
+
+ ldo1 = devm_kzalloc(&pdev->dev, sizeof(*ldo1), GFP_KERNEL);
+ if (!ldo1)
+ return -ENOMEM;
+
+ ldo1->regmap = arizona->regmap;
+
+ /*
+ * Since the chip usually supplies itself we provide some
+ * default init_data for it. This will be overridden with
+ * platform data if provided.
+ */
+ switch (arizona->type) {
+ case WM5102:
+ case WM8997:
+ case WM8998:
+ case WM1814:
+ desc = &arizona_ldo1_hc;
+ ldo1->init_data = arizona_ldo1_dvfs;
+ break;
+ case WM5110:
+ case WM8280:
+ desc = &arizona_ldo1;
+ ldo1->init_data = arizona_ldo1_wm5110;
+ break;
+ default:
+ desc = &arizona_ldo1;
+ ldo1->init_data = arizona_ldo1_default;
+ break;
+ }
+
+ ret = arizona_ldo1_common_init(pdev, ldo1, desc,
+ &arizona->pdata.ldo1,
+ &external_dcvdd);
+ if (ret == 0)
+ arizona->external_dcvdd = external_dcvdd;
+
+ return ret;
+}
+
static struct platform_driver arizona_ldo1_driver = {
.probe = arizona_ldo1_probe,
.driver = {
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Jon Mason @ 2017-04-25 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <44d0c48c-d80f-271e-0e19-ac87a53e2e53@cogentembedded.com>
On Tue, Apr 25, 2017 at 11:23 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello!
>
> On 04/25/2017 06:15 PM, Jon Mason wrote:
>
>>>> Cygnus has a single amac controller connected to the B53 switch with 2
>>>> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
>>>> the external ethernet jacks.
>
>
> [...]
>
>>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>>> ---
>>>> arch/arm/boot/dts/bcm-cygnus.dtsi | 60
>>>> ++++++++++++++++++++++++++++++++++
>>>> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
>>>> 2 files changed, 68 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>>>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>>>> index 009f1346b817..318899df9972 100644
>>>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>>>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>
> [...]
>>>>
>>>> @@ -295,6 +345,16 @@
>>>> status = "disabled";
>>>> };
>>>>
>>>> + eth0: enet at 18042000 {
>>>> + compatible = "brcm,amac";
>>>> + reg = <0x18042000 0x1000>,
>>>> + <0x18110000 0x1000>;
>>>> + reg-names = "amac_base", "idm_base";
>>>
>>>
>>>
>>> I don't think "_base" suffixes are necessary here.
>>
>>
>> 100% necessary, per the driver. See
>> drivers/net/ethernet/broadcom/bgmac-platform.c
>
>
> I'd recommend to fix the driver/bindings then...
They're already in use in other device trees. So, we'd need to
support backward compatibility on them, thus removing any real benefit
to changing them.
>
> MBR, Sergei
>
^ permalink raw reply
* [PATCH 1/2] kvm: Fix mmu_notifier release race
From: Christoffer Dall @ 2017-04-25 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493028624-29837-2-git-send-email-suzuki.poulose@arm.com>
On Mon, Apr 24, 2017 at 11:10:23AM +0100, Suzuki K Poulose wrote:
> The KVM uses mmu_notifier (wherever available) to keep track
> of the changes to the mm of the guest. The guest shadow page
> tables are released when the VM exits via mmu_notifier->ops.release().
> There is a rare chance that the mmu_notifier->release could be
> called more than once via two different paths, which could end
> up in use-after-free of kvm instance (such as [0]).
>
> e.g:
>
> thread A thread B
> ------- --------------
>
> get_signal-> kvm_destroy_vm()->
> do_exit-> mmu_notifier_unregister->
> exit_mm-> kvm_arch_flush_shadow_all()->
> exit_mmap-> spin_lock(&kvm->mmu_lock)
> mmu_notifier_release-> ....
> kvm_arch_flush_shadow_all()-> .....
> ... spin_lock(&kvm->mmu_lock) .....
> spin_unlock(&kvm->mmu_lock)
> kvm_arch_free_kvm()
> *** use after free of kvm ***
>
> This patch attempts to solve the problem by holding a reference to the KVM
> for the mmu_notifier, which is dropped only from notifier->ops.release().
> This will ensure that the KVM struct is available till we reach the
> kvm_mmu_notifier_release, and the kvm_destroy_vm is called only from/after
> it. So, we can unregister the notifier with no_release option and hence
> avoiding the race above. However, we need to make sure that the KVM is
> freed only after the mmu_notifier has finished processing the notifier due to
> the following possible path of execution :
>
> mmu_notifier_release -> kvm_mmu_notifier_release -> kvm_put_kvm ->
> kvm_destroy_vm -> kvm_arch_free_kvm
>
> [0] http://lkml.kernel.org/r/CAAeHK+x8udHKq9xa1zkTO6ax5E8Dk32HYWfaT05FMchL2cr48g at mail.gmail.com
>
> Fixes: commit 85db06e514422 ("KVM: mmu_notifiers release method")
> Reported-by: andreyknvl at google.com
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Radim Kr?m?? <rkrcmar@redhat.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: andreyknvl at google.com
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
This looks good to me, but we should have some KVM generic experts look
at it as well.
Reviewed-by: Christoffer Dall <cdall@linaro.org>
> ---
> include/linux/kvm_host.h | 1 +
> virt/kvm/kvm_main.c | 59 ++++++++++++++++++++++++++++++++++++++++++------
> 2 files changed, 53 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d025074..561e968 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -424,6 +424,7 @@ struct kvm {
> struct mmu_notifier mmu_notifier;
> unsigned long mmu_notifier_seq;
> long mmu_notifier_count;
> + struct rcu_head mmu_notifier_rcu;
> #endif
> long tlbs_dirty;
> struct list_head devices;
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 88257b3..2c3fdd4 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -471,6 +471,7 @@ static void kvm_mmu_notifier_release(struct mmu_notifier *mn,
> idx = srcu_read_lock(&kvm->srcu);
> kvm_arch_flush_shadow_all(kvm);
> srcu_read_unlock(&kvm->srcu, idx);
> + kvm_put_kvm(kvm);
> }
>
> static const struct mmu_notifier_ops kvm_mmu_notifier_ops = {
> @@ -486,8 +487,46 @@ static const struct mmu_notifier_ops kvm_mmu_notifier_ops = {
>
> static int kvm_init_mmu_notifier(struct kvm *kvm)
> {
> + int rc;
> kvm->mmu_notifier.ops = &kvm_mmu_notifier_ops;
> - return mmu_notifier_register(&kvm->mmu_notifier, current->mm);
> + rc = mmu_notifier_register(&kvm->mmu_notifier, current->mm);
> + /*
> + * We hold a reference to KVM here to make sure that the KVM
> + * doesn't get free'd before ops->release() completes.
> + */
> + if (!rc)
> + kvm_get_kvm(kvm);
> + return rc;
> +}
> +
> +static void kvm_free_vm_rcu(struct rcu_head *rcu)
> +{
> + struct kvm *kvm = container_of(rcu, struct kvm, mmu_notifier_rcu);
> + kvm_arch_free_vm(kvm);
> +}
> +
> +static void kvm_flush_shadow_mmu(struct kvm *kvm)
> +{
> + /*
> + * We hold a reference to kvm instance for mmu_notifier and is
> + * only released when ops->release() is called via exit_mmap path.
> + * So, when we reach here ops->release() has been called already, which
> + * flushes the shadow page tables. Hence there is no need to call the
> + * release() again when we unregister the notifier. However, we need
> + * to delay freeing up the kvm until the release() completes, since
> + * we could reach here via :
> + * kvm_mmu_notifier_release() -> kvm_put_kvm() -> kvm_destroy_vm()
> + */
> + mmu_notifier_unregister_no_release(&kvm->mmu_notifier, kvm->mm);
> +}
> +
> +static void kvm_free_vm(struct kvm *kvm)
> +{
> + /*
> + * Wait until the mmu_notifier has finished the release().
> + * See comments above in kvm_flush_shadow_mmu.
> + */
> + mmu_notifier_call_srcu(&kvm->mmu_notifier_rcu, kvm_free_vm_rcu);
> }
>
> #else /* !(CONFIG_MMU_NOTIFIER && KVM_ARCH_WANT_MMU_NOTIFIER) */
> @@ -497,6 +536,16 @@ static int kvm_init_mmu_notifier(struct kvm *kvm)
> return 0;
> }
>
> +static void kvm_flush_shadow_mmu(struct kvm *kvm)
> +{
> + kvm_arch_flush_shadow_all(kvm);
> +}
> +
> +static void kvm_free_vm(struct kvm *kvm)
> +{
> + kvm_arch_free_vm(kvm);
> +}
> +
> #endif /* CONFIG_MMU_NOTIFIER && KVM_ARCH_WANT_MMU_NOTIFIER */
>
> static struct kvm_memslots *kvm_alloc_memslots(void)
> @@ -733,18 +782,14 @@ static void kvm_destroy_vm(struct kvm *kvm)
> kvm->buses[i] = NULL;
> }
> kvm_coalesced_mmio_free(kvm);
> -#if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
> - mmu_notifier_unregister(&kvm->mmu_notifier, kvm->mm);
> -#else
> - kvm_arch_flush_shadow_all(kvm);
> -#endif
> + kvm_flush_shadow_mmu(kvm);
> kvm_arch_destroy_vm(kvm);
> kvm_destroy_devices(kvm);
> for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++)
> kvm_free_memslots(kvm, kvm->memslots[i]);
> cleanup_srcu_struct(&kvm->irq_srcu);
> cleanup_srcu_struct(&kvm->srcu);
> - kvm_arch_free_vm(kvm);
> + kvm_free_vm(kvm);
> preempt_notifier_dec();
> hardware_disable_all();
> mmdrop(mm);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 3/3] drm/sun4i: backend: Clarify sun4i_backend_layer_enable debug message
From: Chen-Yu Tsai @ 2017-04-25 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425152505.6796-1-wens@csie.org>
sun4i_backend_layer_enable can be called to enable or disable a layer.
However the debug message always says "Enable", which is confusing.
This patch makes the debug message vary according to the enable state.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index e9eca057ff35..e53107418add 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -73,7 +73,8 @@ void sun4i_backend_layer_enable(struct sun4i_backend *backend,
{
u32 val;
- DRM_DEBUG_DRIVER("Enabling layer %d\n", layer);
+ DRM_DEBUG_DRIVER("%sabling layer %d\n", enable ? "En" : "Dis",
+ layer);
if (enable)
val = SUN4I_BACKEND_MODCTL_LAY_EN(layer);
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] drm/sun4i: Set TCON clock inside sun4i_tconX_mode_set
From: Chen-Yu Tsai @ 2017-04-25 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425152505.6796-1-wens@csie.org>
Currently we are configuring the TCON's dot clock or special clock
directly from the encoder mode_set functions. Since we already
provide mode_set helper functions for the TCON's 2 channels, we
can set the respective clock from those helpers, and reduce the
exposure of the TCON's internals.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 --
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++++++
drivers/gpu/drm/sun4i/sun4i_tv.c | 2 --
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 1147451eb993..51ece4c39d7e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -175,8 +175,6 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder *encoder,
sun4i_tcon0_mode_set(tcon, mode);
- clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
-
/* FIXME: This seems to be board specific */
clk_set_phase(tcon->dclk, 120);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 8301389c411d..29fd829aa54c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -131,6 +131,9 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
u8 clk_delay;
u32 val = 0;
+ /* Configure the dot clock */
+ clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
+
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
@@ -206,6 +209,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
WARN_ON(!tcon->quirks->has_channel_1);
+ /* Configure the dot clock */
+ clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
+
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 1);
regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 49c49431a053..542da220818b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -486,8 +486,6 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
SUN4I_TVE_RESYNC_FIELD : 0));
regmap_write(tv->regs, SUN4I_TVE_SLAVE_REG, 0);
-
- clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
}
static struct drm_encoder_helper_funcs sun4i_tv_helper_funcs = {
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] drm/sun4i: Drop unused tcon pointer
From: Chen-Yu Tsai @ 2017-04-25 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425152505.6796-1-wens@csie.org>
The sun4i DRM driver now uses 2 lists to track backends and tcons.
During the switch, the original tcon pointer was not removed.
As it is now unused, remove it, so other new drivers can't accidentally
use it.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
As mentioned in the cover letter, please squash this into the patch
drm/sun4i: Use lists to track registered display backends and TCONs
---
drivers/gpu/drm/sun4i/sun4i_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h b/drivers/gpu/drm/sun4i/sun4i_drv.h
index 835bdb5cc0c2..250c29017ef5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.h
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
@@ -20,7 +20,6 @@
struct sun4i_drv {
struct list_head backend_list;
struct list_head tcon_list;
- struct sun4i_tcon *tcon;
struct drm_fbdev_cma *fbdev;
};
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3] drm/sun4i: More cleanups and fixes
From: Chen-Yu Tsai @ 2017-04-25 15:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Maxime,
The subject is probably getting old. Here are a few more cleanups.
Patch 1 should have been part of the patch
drm/sun4i: Use lists to track registered display backends and TCONs
from my multiple pipeline support series. Please squash it in if you can.
Patch 2 just moves setting the TCON clocks back inside the TCON driver.
Patch 3 cleans up a DRM driver debug message.
Regards
ChenYu
Chen-Yu Tsai (3):
drm/sun4i: Drop unused tcon pointer
drm/sun4i: Set TCON clock inside sun4i_tconX_mode_set
drm/sun4i: backend: Clarify sun4i_backend_layer_enable debug message
drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++-
drivers/gpu/drm/sun4i/sun4i_drv.h | 1 -
drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 --
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++++++
drivers/gpu/drm/sun4i/sun4i_tv.c | 2 --
5 files changed, 8 insertions(+), 6 deletions(-)
--
2.11.0
^ permalink raw reply
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Fabio Estevam @ 2017-04-25 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7x+6KwOZdC1MaNQGdXWFjJ18hYp3kc73JADDMC4DOFn+yQ@mail.gmail.com>
On Tue, Apr 25, 2017 at 11:35 AM, Adam Ford <aford173@gmail.com> wrote:
> I have a touch screen (using tsc2004 touch controller) on my board. I
> can run some tests if you tell me how you're able to reproduce your
> issue. I can at least confirm whether or not I see it too. I won't
> be able to do it until later tonight or tomorrow however.
Just run:
evtest /dev/input/eventX to capture the touchscreen events and keep
touching the screen.
After some random time (1-2 minutes) evtest will stop capturing the events.
Thanks
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Sergei Shtylyov @ 2017-04-25 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAC3K-4qn5oCXvyMCkFESGqMHqHXGiNUW6wfRx2LUZ8qZ39qroQ@mail.gmail.com>
Hello!
On 04/25/2017 06:15 PM, Jon Mason wrote:
>>> Cygnus has a single amac controller connected to the B53 switch with 2
>>> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
>>> the external ethernet jacks.
[...]
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>> ---
>>> arch/arm/boot/dts/bcm-cygnus.dtsi | 60
>>> ++++++++++++++++++++++++++++++++++
>>> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
>>> 2 files changed, 68 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>>> index 009f1346b817..318899df9972 100644
>>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
[...]
>>> @@ -295,6 +345,16 @@
>>> status = "disabled";
>>> };
>>>
>>> + eth0: enet at 18042000 {
>>> + compatible = "brcm,amac";
>>> + reg = <0x18042000 0x1000>,
>>> + <0x18110000 0x1000>;
>>> + reg-names = "amac_base", "idm_base";
>>
>>
>> I don't think "_base" suffixes are necessary here.
>
> 100% necessary, per the driver. See
> drivers/net/ethernet/broadcom/bgmac-platform.c
I'd recommend to fix the driver/bindings then...
MBR, Sergei
^ permalink raw reply
* [PATCH] usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
From: Stefan Wahren @ 2017-04-25 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB1450634CE9C1D7FACC37DB4A8B1E0@HE1PR04MB1450.eurprd04.prod.outlook.com>
Am 25.04.2017 um 11:20 schrieb Peter Chen:
>
>>>> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
>>>> index f88e9157fad0..60a786c87c06 100644
>>>> --- a/drivers/usb/chipidea/udc.c
>>>> +++ b/drivers/usb/chipidea/udc.c
>>>> @@ -1984,6 +1984,7 @@ static void udc_id_switch_for_host(struct
>>>> ci_hdrc *ci) int ci_hdrc_gadget_init(struct ci_hdrc *ci) {
>>>> struct ci_role_driver *rdrv;
>>>> + int ret;
>>>>
>>>> if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_DC))
>>>> return -ENXIO;
>>>> @@ -1996,7 +1997,10 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
>>>> rdrv->stop = udc_id_switch_for_host;
>>>> rdrv->irq = udc_irq;
>>>> rdrv->name = "gadget";
>>>> - ci->roles[CI_ROLE_GADGET] = rdrv;
>>>>
>>>> - return udc_start(ci);
>>>> + ret = udc_start(ci);
>>>> + if (!ret)
>>>> + ci->roles[CI_ROLE_GADGET] = rdrv;
>>>> +
>>>> + return ret;
>>>> }
>>>> --
>>> Thanks for fixing it. In fact, we'd better return failure if ret &&
>>> ret != -ENXIO at probe, it stands for initialization for host or
>>> gadget has failed.
>>>
>> I got your meaning. I'll cook v2. I don't have preference, since either one can fix the
>> issue.
>>
> Both are needed, you don't need to send this one again. Only a new one, thanks.
I'm not sure how easy it is to reproduce the issue.
Shouldn't make a Fixes tag sense at least?
>
> Peter
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: fix the overlap between the kernel image and vmalloc address
From: Ard Biesheuvel @ 2017-04-25 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425150212.GF3792@leverpostej>
On 25 April 2017 at 16:02, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Apr 24, 2017 at 06:56:43PM +0100, Ard Biesheuvel wrote:
>> On 24 April 2017 at 18:52, Laura Abbott <labbott@redhat.com> wrote:
>> > On 04/24/2017 08:51 AM, Mark Rutland wrote:
>> >> On Mon, Apr 24, 2017 at 09:28:48PM +0800, zhong jiang wrote:
>
>> >> static struct page *kernel_image_to_page(const void *addr)
>> >> {
>> >> return virt_to_page(lm_alias(vmalloc_addr));
>> >> }
>> >>
>> >>> +
>> >>> /*
>> >>> * Walk a vmap address to the struct page it maps.
>> >>> */
>> >>> @@ -244,6 +280,9 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>> >>> */
>> >>> VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
>> >>>
>> >>> + if (is_kernel_image_addr(vmalloc_addr))
>> >>> + return kernel_image_to_page(vmalloc_addr, pgd);
>> >>
>> >> It's not clear to me that this is the right place for this to live.
>> >>
>> >> It might be best to code the kernel image logic directly in kcore (and
>> >> kmem), assuming everyone's OK with that approach.
>> >>
>> >
>> > That will fix kcore and kmem but this will show up in other places too.
>> > We've gone through and made sure that virt_addr_valid returns
>> > true if and only if virt_to_page returns a valid address. I don't know
>> > if we can make as strong a claim about is_vmalloc_addr and
>> > vmalloc_to_page in all cases but is_vmalloc_addr should not return true
>> > for the kernel image. That would at least let kcore fall back to
>> > kern_addr_valid which should correctly handle the kernel image.
>> > The suggestion to move the kernel image out of VMALLOC_START/VMALLOC_END
>> > seems like the best approach although I haven't tried a prototype
>> > at all.
>>
>> Moving the kernel into the vmalloc region was kind of the point, for
>> KASLR. Undoing that means either disabling KASLR, or splitting the
>> vmalloc region into a KASLR region only for the kernel, and a vmalloc
>> region like we had when vmlinux lived in the linear region.
>
> AFAICT, x86 don't place the kernel in the vmalloc region for its KASLR
> implementation. Is that just to avoid the issues that we're seeing, or
> are there aother constraints on x86?
>
Given how a lot of architectures put kernel modules in the vmalloc
space, I don't think there is generally an issue with putting the
kernel there as well, other than what we are currently experiencing.
As discussed, ioremap regions are also likely to be mapped using block
mappings these days, and also reside between VMALLOC_START and
VMALLOC_END.
So in my opinion, since
a) we already put text and data in the vmalloc region, and
b) we already use block mappings in the vmalloc region
putting the kernel there is only a minor variation of what we already
have to deal with, and so I don't think there is anything wrong with
it. We simply have to tweak some tests here and there, but nothing
fundamental afaict.
>> In general, I think we should be able to deal with different kinds of
>> mappings with different granularity in the vmalloc region. If
>> necessary, we could introduce a VM_xxx flag for the kernel to
>> distinguish such regions from ordinary VM_MAP regions.
>
> I don't think that vmalloc_to_page() should have to deal with anything
> other than the usual page-granular memory mappings in the vmalloc area,
> as it currently does. We'd have to write a page table walker per-arch
> for that to work, and the only thing it would benefit is arm64's kernel
> image mapping.
>
> Adding VM_xxx (e.g. VM_KERNEL) sounds sane to me regardless of anything
> else.
>
> That still leaves the question as to what is_vmalloc_addr(addr) (should)
> imply about addr, though.
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Jon Mason @ 2017-04-25 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f870339f-2fa1-411d-5ce8-adbe8802d8a8@cogentembedded.com>
On Tue, Apr 25, 2017 at 5:40 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
> On 4/25/2017 12:50 AM, Eric Anholt wrote:
>
>> Cygnus has a single amac controller connected to the B53 switch with 2
>> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
>> the external ethernet jacks.
>
>
> My spell checker trips on "amac" and "ethernet" -- perhaps they need
> capitalization?
>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>> arch/arm/boot/dts/bcm-cygnus.dtsi | 60
>> ++++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
>> 2 files changed, 68 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 009f1346b817..318899df9972 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -142,6 +142,56 @@
>> interrupts = <0>;
>> };
>>
>> + mdio: mdio at 18002000 {
>> + compatible = "brcm,iproc-mdio";
>> + reg = <0x18002000 0x8>;
>> + #size-cells = <1>;
>> + #address-cells = <0>;
>> +
>> + gphy0: eth-gphy at 0 {
>
>
> The node anmes must be generic, the DT spec has standardized
> "ethernet-phy" name for this case.
>
>> + reg = <0>;
>> + max-speed = <1000>;
>> + };
>> +
>> + gphy1: eth-gphy at 1 {
>> + reg = <1>;
>> + max-speed = <1000>;
>> + };
>> + };
>
> [...]
>>
>> @@ -295,6 +345,16 @@
>> status = "disabled";
>> };
>>
>> + eth0: enet at 18042000 {
>> + compatible = "brcm,amac";
>> + reg = <0x18042000 0x1000>,
>> + <0x18110000 0x1000>;
>> + reg-names = "amac_base", "idm_base";
>
>
> I don't think "_base" suffixes are necessary here.
100% necessary, per the driver. See
drivers/net/ethernet/broadcom/bgmac-platform.c
>
> [...]
>
> MBR, Sergei
>
^ permalink raw reply
* [PATCH v2] arm64: fix the overlap between the kernel image and vmalloc address
From: zhongjiang @ 2017-04-25 15:09 UTC (permalink / raw)
To: linux-arm-kernel
Recently, xiaojun report the following issue.
[ 4544.984139] Unable to handle kernel paging request at virtual address ffff804392800000
[ 4544.991995] pgd = ffff80096745f000
[ 4544.995369] [ffff804392800000] *pgd=0000000000000000
[ 4545.000297] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 4545.005815] Modules linked in:
[ 4545.008843] CPU: 1 PID: 8976 Comm: cat Not tainted 4.11.0-rc6 #1
[ 4545.014790] Hardware name: ARM Juno development board (r1) (DT)
[ 4545.020653] task: ffff8009753fdb00 task.stack: ffff80097533c000
[ 4545.026520] PC is at __memcpy+0x100/0x180
[ 4545.030491] LR is at vread+0x144/0x280
[ 4545.034202] pc : [<ffff0000083a1000>] lr : [<ffff0000081c126c>] pstate: 20000145
[ 4545.041530] sp : ffff80097533fcb0
[ 4545.044811] x29: ffff80097533fcb0 x28: ffff800962d24000
[ 4545.050074] x27: 0000000000001000 x26: ffff8009753fdb00
[ 4545.055337] x25: ffff000008200000 x24: ffff800977801380
[ 4545.060600] x23: ffff8009753fdb00 x22: ffff800962d24000
[ 4545.065863] x21: 0000000000001000 x20: ffff000008200000
[ 4545.071125] x19: 0000000000001000 x18: 0000ffffefa323c0
[ 4545.076387] x17: 0000ffffa9c87440 x16: ffff0000081fdfd0
[ 4545.081649] x15: 0000ffffa9d01588 x14: 72a77346b2407be7
[ 4545.086911] x13: 5299400690000000 x12: b0000001f9001a79
[ 4545.092173] x11: 97fc098d91042260 x10: 0000000000000000
[ 4545.097435] x9 : 0000000000000000 x8 : 9110626091260021
[ 4545.102698] x7 : 0000000000001000 x6 : ffff800962d24000
[ 4545.107960] x5 : ffff8009778013b0 x4 : 0000000000000000
[ 4545.113222] x3 : 0400000000000001 x2 : 0000000000000f80
[ 4545.118484] x1 : ffff804392800000 x0 : ffff800962d24000
[ 4545.123745]
[ 4545.125220] Process cat (pid: 8976, stack limit = 0xffff80097533c000)
[ 4545.131598] Stack: (0xffff80097533fcb0 to 0xffff800975340000)
[ 4545.137289] fca0: ffff80097533fd30 ffff000008270f64
[ 4545.145049] fcc0: 000000000000e000 000000003956f000 ffff000008f950d0 ffff80097533feb8
[ 4545.152809] fce0: 0000000000002000 ffff8009753fdb00 ffff800962d24000 ffff000008e8d3d8
[ 4545.160568] fd00: 0000000000001000 ffff000008200000 0000000000001000 ffff800962d24000
[ 4545.168327] fd20: 0000000000001000 ffff000008e884a0 ffff80097533fdb0 ffff00000826340c
[ 4545.176086] fd40: ffff800976bf2800 fffffffffffffffb 000000003956d000 ffff80097533feb8
[ 4545.183846] fd60: 0000000060000000 0000000000000015 0000000000000124 000000000000003f
[ 4545.191605] fd80: ffff000008962000 ffff8009753fdb00 ffff8009753fdb00 ffff8009753fdb00
[ 4545.199364] fda0: 0000000300000124 0000000000002000 ffff80097533fdd0 ffff0000081fb83c
[ 4545.207123] fdc0: 0000000000010000 ffff80097514f900 ffff80097533fe50 ffff0000081fcb28
[ 4545.214883] fde0: 0000000000010000 ffff80097514f900 0000000000000000 0000000000000000
[ 4545.222642] fe00: ffff80097533fe30 ffff0000081fca1c ffff80097514f900 0000000000000000
[ 4545.230401] fe20: 000000003956d000 ffff80097533feb8 ffff80097533fe50 ffff0000081fcb04
[ 4545.238160] fe40: 0000000000010000 ffff80097514f900 ffff80097533fe80 ffff0000081fe014
[ 4545.245919] fe60: ffff80097514f900 ffff80097514f900 000000003956d000 0000000000010000
[ 4545.253678] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800977146000
[ 4545.261438] fea0: ffffffffffffffff 0000ffffa9c8745c 0000000000000124 0000000008202000
[ 4545.269197] fec0: 0000000000000003 000000003956d000 0000000000010000 0000000000000000
[ 4545.276956] fee0: 0000000000011011 0000000000000001 0000000000000011 0000000000000002
[ 4545.284715] ff00: 000000000000003f 1f3c201f7372686b 00000000ffffffff 0000000000000030
[ 4545.292474] ff20: 0000000000000038 0000000000000000 0000ffffa9bcca94 0000ffffa9d01588
[ 4545.300233] ff40: 0000000000000000 0000ffffa9c87440 0000ffffefa323c0 0000000000010000
[ 4545.307993] ff60: 000000000041a310 000000003956d000 0000000000000003 000000007fffe000
[ 4545.315751] ff80: 00000000004088d0 0000000000010000 0000000000000000 0000000000000000
[ 4545.323511] ffa0: 0000000000010000 0000ffffefa32690 0000000000404dcc 0000ffffefa32690
[ 4545.331270] ffc0: 0000ffffa9c8745c 0000000060000000 0000000000000003 000000000000003f
[ 4545.339029] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4545.346786] Call trace:
[ 4545.349207] Exception stack(0xffff80097533fae0 to 0xffff80097533fc10)
[ 4545.355586] fae0: 0000000000001000 0001000000000000 ffff80097533fcb0 ffff0000083a1000
[ 4545.363345] fb00: 000000003957c000 ffff80097533fc00 0000000020000145 0000000000000025
[ 4545.371105] fb20: ffff800962d24000 ffff000008e8d3d8 0000000000001000 ffff8009753fdb00
[ 4545.378864] fb40: 0000000000000000 0000000000000002 ffff80097533fd30 ffff000008082604
[ 4545.386623] fb60: 0000000000001000 0001000000000000 ffff80097533fd30 ffff0000083a0a90
[ 4545.394382] fb80: ffff800962d24000 ffff804392800000 0000000000000f80 0400000000000001
[ 4545.402140] fba0: 0000000000000000 ffff8009778013b0 ffff800962d24000 0000000000001000
[ 4545.409899] fbc0: 9110626091260021 0000000000000000 0000000000000000 97fc098d91042260
[ 4545.417658] fbe0: b0000001f9001a79 5299400690000000 72a77346b2407be7 0000ffffa9d01588
[ 4545.425416] fc00: ffff0000081fdfd0 0000ffffa9c87440
[ 4545.430248] [<ffff0000083a1000>] __memcpy+0x100/0x180
[ 4545.435253] [<ffff000008270f64>] read_kcore+0x21c/0x3b0
[ 4545.440429] [<ffff00000826340c>] proc_reg_read+0x64/0x90
[ 4545.445691] [<ffff0000081fb83c>] __vfs_read+0x1c/0x108
[ 4545.450779] [<ffff0000081fcb28>] vfs_read+0x80/0x130
[ 4545.455696] [<ffff0000081fe014>] SyS_read+0x44/0xa0
[ 4545.460528] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[ 4545.465790] Code: d503201f d503201f d503201f d503201f (a8c12027)
[ 4545.471852] ---[ end trace 4d1897f94759f461 ]---
[ 4545.476435] note: cat[8976] exited with preempt_count 2
I find the issue is introduced when applying commit f9040773b7bb
("arm64: move kernel image to base of vmalloc area"). This patch
make the kernel image overlap with vmalloc area. It will result in
vmalloc area have the huge page table. but the vmalloc_to_page is
not realize the change. and the function is public to any arch.
I fix it by adding the another kernel image condition in vmalloc_to_page
to make it keep the accordance with previous vmalloc mapping.
Fixes: f9040773b7bb ("arm64: move kernel image to base of vmalloc area")
Reported-by: tan xiaojun <tanxiaojun@huawei.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: zhongjiang <zhongjiang@huawei.com>
---
v2
Reimplement the fix by adding the kernel_image_addr helper function.
instead by the previos fix by forcing the kernel image page table to
set up in page granularity. beacuse it will bring in TLB pressure.
include/linux/mm.h | 8 ++++++++
mm/vmalloc.c | 14 ++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 6ad0ef6..1cc8156 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -509,6 +509,14 @@ static inline bool is_vmalloc_addr(const void *x)
return false;
#endif
}
+
+static inline bool is_kernel_image_addr(const void *x)
+{
+ unsigned long addr = (unsigned long)x;
+
+ return addr >= (unsigned long)_stext && addr < (unsigned long)_end;
+}
+
#ifdef CONFIG_MMU
extern int is_vmalloc_or_module_addr(const void *x);
#else
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 68eb002..19b9c6e 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -262,6 +262,11 @@ int is_vmalloc_or_module_addr(const void *x)
return is_vmalloc_addr(x);
}
+static struct page *kernel_image_to_page(const void *addr)
+{
+ return virt_to_page(lm_alias(addr));
+}
+
/*
* Walk a vmap address to the struct page it maps.
*/
@@ -281,6 +286,15 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
*/
VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
+ /*
+ * kenrel image overlap with the vmalloc area in arm64, it will
+ * make the huge talbe page existence, if we walk the all page
+ * talbe, it may be result in the panic. Add the following code,
+ * it will keep consistent with previous behavior.
+ */
+ if (is_kernel_image_addr(vmalloc_addr))
+ return kernel_image_to_page(vmalloc_addr);
+
if (pgd_none(*pgd))
return NULL;
p4d = p4d_offset(pgd, addr);
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2] arm64: fix the overlap between the kernel image and vmalloc address
From: zhongjiang @ 2017-04-25 15:03 UTC (permalink / raw)
To: linux-arm-kernel
Recently, xiaojun report the following issue.
[ 4544.984139] Unable to handle kernel paging request at virtual address ffff804392800000
[ 4544.991995] pgd = ffff80096745f000
[ 4544.995369] [ffff804392800000] *pgd=0000000000000000
[ 4545.000297] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 4545.005815] Modules linked in:
[ 4545.008843] CPU: 1 PID: 8976 Comm: cat Not tainted 4.11.0-rc6 #1
[ 4545.014790] Hardware name: ARM Juno development board (r1) (DT)
[ 4545.020653] task: ffff8009753fdb00 task.stack: ffff80097533c000
[ 4545.026520] PC is at __memcpy+0x100/0x180
[ 4545.030491] LR is at vread+0x144/0x280
[ 4545.034202] pc : [<ffff0000083a1000>] lr : [<ffff0000081c126c>] pstate: 20000145
[ 4545.041530] sp : ffff80097533fcb0
[ 4545.044811] x29: ffff80097533fcb0 x28: ffff800962d24000
[ 4545.050074] x27: 0000000000001000 x26: ffff8009753fdb00
[ 4545.055337] x25: ffff000008200000 x24: ffff800977801380
[ 4545.060600] x23: ffff8009753fdb00 x22: ffff800962d24000
[ 4545.065863] x21: 0000000000001000 x20: ffff000008200000
[ 4545.071125] x19: 0000000000001000 x18: 0000ffffefa323c0
[ 4545.076387] x17: 0000ffffa9c87440 x16: ffff0000081fdfd0
[ 4545.081649] x15: 0000ffffa9d01588 x14: 72a77346b2407be7
[ 4545.086911] x13: 5299400690000000 x12: b0000001f9001a79
[ 4545.092173] x11: 97fc098d91042260 x10: 0000000000000000
[ 4545.097435] x9 : 0000000000000000 x8 : 9110626091260021
[ 4545.102698] x7 : 0000000000001000 x6 : ffff800962d24000
[ 4545.107960] x5 : ffff8009778013b0 x4 : 0000000000000000
[ 4545.113222] x3 : 0400000000000001 x2 : 0000000000000f80
[ 4545.118484] x1 : ffff804392800000 x0 : ffff800962d24000
[ 4545.123745]
[ 4545.125220] Process cat (pid: 8976, stack limit = 0xffff80097533c000)
[ 4545.131598] Stack: (0xffff80097533fcb0 to 0xffff800975340000)
[ 4545.137289] fca0: ffff80097533fd30 ffff000008270f64
[ 4545.145049] fcc0: 000000000000e000 000000003956f000 ffff000008f950d0 ffff80097533feb8
[ 4545.152809] fce0: 0000000000002000 ffff8009753fdb00 ffff800962d24000 ffff000008e8d3d8
[ 4545.160568] fd00: 0000000000001000 ffff000008200000 0000000000001000 ffff800962d24000
[ 4545.168327] fd20: 0000000000001000 ffff000008e884a0 ffff80097533fdb0 ffff00000826340c
[ 4545.176086] fd40: ffff800976bf2800 fffffffffffffffb 000000003956d000 ffff80097533feb8
[ 4545.183846] fd60: 0000000060000000 0000000000000015 0000000000000124 000000000000003f
[ 4545.191605] fd80: ffff000008962000 ffff8009753fdb00 ffff8009753fdb00 ffff8009753fdb00
[ 4545.199364] fda0: 0000000300000124 0000000000002000 ffff80097533fdd0 ffff0000081fb83c
[ 4545.207123] fdc0: 0000000000010000 ffff80097514f900 ffff80097533fe50 ffff0000081fcb28
[ 4545.214883] fde0: 0000000000010000 ffff80097514f900 0000000000000000 0000000000000000
[ 4545.222642] fe00: ffff80097533fe30 ffff0000081fca1c ffff80097514f900 0000000000000000
[ 4545.230401] fe20: 000000003956d000 ffff80097533feb8 ffff80097533fe50 ffff0000081fcb04
[ 4545.238160] fe40: 0000000000010000 ffff80097514f900 ffff80097533fe80 ffff0000081fe014
[ 4545.245919] fe60: ffff80097514f900 ffff80097514f900 000000003956d000 0000000000010000
[ 4545.253678] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800977146000
[ 4545.261438] fea0: ffffffffffffffff 0000ffffa9c8745c 0000000000000124 0000000008202000
[ 4545.269197] fec0: 0000000000000003 000000003956d000 0000000000010000 0000000000000000
[ 4545.276956] fee0: 0000000000011011 0000000000000001 0000000000000011 0000000000000002
[ 4545.284715] ff00: 000000000000003f 1f3c201f7372686b 00000000ffffffff 0000000000000030
[ 4545.292474] ff20: 0000000000000038 0000000000000000 0000ffffa9bcca94 0000ffffa9d01588
[ 4545.300233] ff40: 0000000000000000 0000ffffa9c87440 0000ffffefa323c0 0000000000010000
[ 4545.307993] ff60: 000000000041a310 000000003956d000 0000000000000003 000000007fffe000
[ 4545.315751] ff80: 00000000004088d0 0000000000010000 0000000000000000 0000000000000000
[ 4545.323511] ffa0: 0000000000010000 0000ffffefa32690 0000000000404dcc 0000ffffefa32690
[ 4545.331270] ffc0: 0000ffffa9c8745c 0000000060000000 0000000000000003 000000000000003f
[ 4545.339029] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4545.346786] Call trace:
[ 4545.349207] Exception stack(0xffff80097533fae0 to 0xffff80097533fc10)
[ 4545.355586] fae0: 0000000000001000 0001000000000000 ffff80097533fcb0 ffff0000083a1000
[ 4545.363345] fb00: 000000003957c000 ffff80097533fc00 0000000020000145 0000000000000025
[ 4545.371105] fb20: ffff800962d24000 ffff000008e8d3d8 0000000000001000 ffff8009753fdb00
[ 4545.378864] fb40: 0000000000000000 0000000000000002 ffff80097533fd30 ffff000008082604
[ 4545.386623] fb60: 0000000000001000 0001000000000000 ffff80097533fd30 ffff0000083a0a90
[ 4545.394382] fb80: ffff800962d24000 ffff804392800000 0000000000000f80 0400000000000001
[ 4545.402140] fba0: 0000000000000000 ffff8009778013b0 ffff800962d24000 0000000000001000
[ 4545.409899] fbc0: 9110626091260021 0000000000000000 0000000000000000 97fc098d91042260
[ 4545.417658] fbe0: b0000001f9001a79 5299400690000000 72a77346b2407be7 0000ffffa9d01588
[ 4545.425416] fc00: ffff0000081fdfd0 0000ffffa9c87440
[ 4545.430248] [<ffff0000083a1000>] __memcpy+0x100/0x180
[ 4545.435253] [<ffff000008270f64>] read_kcore+0x21c/0x3b0
[ 4545.440429] [<ffff00000826340c>] proc_reg_read+0x64/0x90
[ 4545.445691] [<ffff0000081fb83c>] __vfs_read+0x1c/0x108
[ 4545.450779] [<ffff0000081fcb28>] vfs_read+0x80/0x130
[ 4545.455696] [<ffff0000081fe014>] SyS_read+0x44/0xa0
[ 4545.460528] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[ 4545.465790] Code: d503201f d503201f d503201f d503201f (a8c12027)
[ 4545.471852] ---[ end trace 4d1897f94759f461 ]---
[ 4545.476435] note: cat[8976] exited with preempt_count 2
I find the issue is introduced when applying commit f9040773b7bb
("arm64: move kernel image to base of vmalloc area"). This patch
make the kernel image overlap with vmalloc area. It will result in
vmalloc area have the huge page table. but the vmalloc_to_page is
not realize the change. and the function is public to any arch.
I fix it by adding the another kernel image condition in vmalloc_to_page
to make it keep the accordance with previous vmalloc mapping.
Fixes: f9040773b7bb ("arm64: move kernel image to base of vmalloc area")
Reported-by: tan xiaojun <tanxiaojun@huawei.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: zhongjiang <zhongjiang@huawei.com>
---
v2
Reimplement the fix by adding the kernel_image_addr helper function.
instead by the previos fix by forcing the kernel image page table to
set up in page granularity. beacuse it will bring in TLB pressure.
include/linux/mm.h | 8 ++++++++
mm/vmalloc.c | 14 ++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 6ad0ef6..2b45b46 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -509,6 +509,14 @@ static inline bool is_vmalloc_addr(const void *x)
return false;
#endif
}
+
+static inline bool is_kernel_image_addr(const void *x)
+{
+ unsigned long addr = (unsigned long)x;
+
+ return addr >= (unsigned long)_stext && add < (unsigned long)_end;
+}
+
#ifdef CONFIG_MMU
extern int is_vmalloc_or_module_addr(const void *x);
#else
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 68eb002..19b9c6e 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -262,6 +262,11 @@ int is_vmalloc_or_module_addr(const void *x)
return is_vmalloc_addr(x);
}
+static struct page *kernel_image_to_page(const void *addr)
+{
+ return virt_to_page(lm_alias(addr));
+}
+
/*
* Walk a vmap address to the struct page it maps.
*/
@@ -281,6 +286,15 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
*/
VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
+ /*
+ * kenrel image overlap with the vmalloc area in arm64, it will
+ * make the huge talbe page existence, if we walk the all page
+ * talbe, it may be result in the panic. Add the following code,
+ * it will keep consistent with previous behavior.
+ */
+ if (is_kernel_image_addr(vmalloc_addr))
+ return kernel_image_to_page(vmalloc_addr);
+
if (pgd_none(*pgd))
return NULL;
p4d = p4d_offset(pgd, addr);
--
1.7.12.4
^ permalink raw reply related
* [PATCH] arm64: fix the overlap between the kernel image and vmalloc address
From: Mark Rutland @ 2017-04-25 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9RuJC9LgsEDSf91x4gV+VoRTLTjA9hGoPAu1ZkFDODmA@mail.gmail.com>
On Mon, Apr 24, 2017 at 06:56:43PM +0100, Ard Biesheuvel wrote:
> On 24 April 2017 at 18:52, Laura Abbott <labbott@redhat.com> wrote:
> > On 04/24/2017 08:51 AM, Mark Rutland wrote:
> >> On Mon, Apr 24, 2017 at 09:28:48PM +0800, zhong jiang wrote:
> >> static struct page *kernel_image_to_page(const void *addr)
> >> {
> >> return virt_to_page(lm_alias(vmalloc_addr));
> >> }
> >>
> >>> +
> >>> /*
> >>> * Walk a vmap address to the struct page it maps.
> >>> */
> >>> @@ -244,6 +280,9 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
> >>> */
> >>> VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
> >>>
> >>> + if (is_kernel_image_addr(vmalloc_addr))
> >>> + return kernel_image_to_page(vmalloc_addr, pgd);
> >>
> >> It's not clear to me that this is the right place for this to live.
> >>
> >> It might be best to code the kernel image logic directly in kcore (and
> >> kmem), assuming everyone's OK with that approach.
> >>
> >
> > That will fix kcore and kmem but this will show up in other places too.
> > We've gone through and made sure that virt_addr_valid returns
> > true if and only if virt_to_page returns a valid address. I don't know
> > if we can make as strong a claim about is_vmalloc_addr and
> > vmalloc_to_page in all cases but is_vmalloc_addr should not return true
> > for the kernel image. That would at least let kcore fall back to
> > kern_addr_valid which should correctly handle the kernel image.
> > The suggestion to move the kernel image out of VMALLOC_START/VMALLOC_END
> > seems like the best approach although I haven't tried a prototype
> > at all.
>
> Moving the kernel into the vmalloc region was kind of the point, for
> KASLR. Undoing that means either disabling KASLR, or splitting the
> vmalloc region into a KASLR region only for the kernel, and a vmalloc
> region like we had when vmlinux lived in the linear region.
AFAICT, x86 don't place the kernel in the vmalloc region for its KASLR
implementation. Is that just to avoid the issues that we're seeing, or
are there aother constraints on x86?
> In general, I think we should be able to deal with different kinds of
> mappings with different granularity in the vmalloc region. If
> necessary, we could introduce a VM_xxx flag for the kernel to
> distinguish such regions from ordinary VM_MAP regions.
I don't think that vmalloc_to_page() should have to deal with anything
other than the usual page-granular memory mappings in the vmalloc area,
as it currently does. We'd have to write a page table walker per-arch
for that to work, and the only thing it would benefit is arm64's kernel
image mapping.
Adding VM_xxx (e.g. VM_KERNEL) sounds sane to me regardless of anything
else.
That still leaves the question as to what is_vmalloc_addr(addr) (should)
imply about addr, though.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: fix the overlap between the kernel image and vmalloc address
From: Mark Rutland @ 2017-04-25 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ffd0a3c5-5d89-4bbd-9995-c545bccaa8f6@redhat.com>
On Mon, Apr 24, 2017 at 10:52:08AM -0700, Laura Abbott wrote:
> On 04/24/2017 08:51 AM, Mark Rutland wrote:
> > On Mon, Apr 24, 2017 at 09:28:48PM +0800, zhong jiang wrote:
> >> /*
> >> * Walk a vmap address to the struct page it maps.
> >> */
> >> @@ -244,6 +280,9 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
> >> */
> >> VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
> >>
> >> + if (is_kernel_image_addr(vmalloc_addr))
> >> + return kernel_image_to_page(vmalloc_addr, pgd);
> >
> > It's not clear to me that this is the right place for this to live.
> >
> > It might be best to code the kernel image logic directly in kcore (and
> > kmem), assuming everyone's OK with that approach.
> >
>
> That will fix kcore and kmem but this will show up in other places too.
True.
> We've gone through and made sure that virt_addr_valid returns
> true if and only if virt_to_page returns a valid address. I don't know
> if we can make as strong a claim about is_vmalloc_addr and
> vmalloc_to_page in all cases but is_vmalloc_addr should not return true
> for the kernel image. That would at least let kcore fall back to
> kern_addr_valid which should correctly handle the kernel image.
That would largely be my preference.
My fear is that other users of is_vmalloc_addr() are doing the right
thing for the kernel image today (e.g. not doing virt_to_phys()),
because they see it as a vmalloc addr.
So we might have to audit all of those.
> The suggestion to move the kernel image out of VMALLOC_START/VMALLOC_END
> seems like the best approach although I haven't tried a prototype
> at all.
Given that (AFAICT) we're the only architecture that puts the kernel in
the vmalloc area, I agree that this is likely to be the simplest correct
approach. The interaction with KASLR is somewhat unfortunate.
Thanks,
Mark.
^ permalink raw reply
* [kvmtool PATCH v10 15/15] arm64: enable GICv3-ITS emulation
From: Andre Przywara @ 2017-04-25 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425143932.17235-1-andre.przywara@arm.com>
With everything in place for the ITS emulation add a new option to the
--irqchip parameter to allow the user to specify --irqchip=gicv3-its
to enable the ITS emulation.
This will trigger creating the FDT node and an ITS register frame to
tell the kernel we want ITS emulation in the guest.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arm/gic.c | 2 ++
arm/include/arm-common/kvm-config-arch.h | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arm/gic.c b/arm/gic.c
index d9c3175..9de6a9c 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -26,6 +26,8 @@ int irqchip_parser(const struct option *opt, const char *arg, int unset)
*type = IRQCHIP_GICV2;
} else if (!strcmp(arg, "gicv3")) {
*type = IRQCHIP_GICV3;
+ } else if (!strcmp(arg, "gicv3-its")) {
+ *type = IRQCHIP_GICV3_ITS;
} else {
pr_err("irqchip: unknown type \"%s\"\n", arg);
return -1;
diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
index ed626b5..b48e720 100644
--- a/arm/include/arm-common/kvm-config-arch.h
+++ b/arm/include/arm-common/kvm-config-arch.h
@@ -27,7 +27,7 @@ int irqchip_parser(const struct option *opt, const char *arg, int unset);
"Force virtio devices to use PCI as their default " \
"transport"), \
OPT_CALLBACK('\0', "irqchip", &(cfg)->irqchip, \
- "[gicv2|gicv3]", \
+ "[gicv2|gicv3|gicv3-its]", \
"Type of interrupt controller to emulate in the guest", \
irqchip_parser, NULL),
--
2.9.0
^ permalink raw reply related
* [kvmtool PATCH v10 14/15] extend GSI IRQ routing to take a device ID
From: Andre Przywara @ 2017-04-25 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425143932.17235-1-andre.przywara@arm.com>
For ITS emulation we need the device ID along with the MSI payload
and doorbell address to identify an MSI, so we need to put it in the
GSI IRQ routing table too.
There is a per-VM capability by which the kernel signals the need for
a device ID, so check this and put the device ID into the routing
table if needed.
For PCI devices we take the bus/device/function triplet and and that
to the routing setup call.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
hw/pci-shmem.c | 3 ++-
include/kvm/irq.h | 2 +-
irq.c | 10 ++++++++--
virtio/pci.c | 6 ++++--
4 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/hw/pci-shmem.c b/hw/pci-shmem.c
index 7ce98cb..512b5b0 100644
--- a/hw/pci-shmem.c
+++ b/hw/pci-shmem.c
@@ -135,7 +135,8 @@ int pci_shmem__get_local_irqfd(struct kvm *kvm)
return fd;
if (pci_shmem_pci_device.msix.ctrl & cpu_to_le16(PCI_MSIX_FLAGS_ENABLE)) {
- gsi = irq__add_msix_route(kvm, &msix_table[0].msg);
+ gsi = irq__add_msix_route(kvm, &msix_table[0].msg,
+ pci_shmem_device.dev_num << 3);
if (gsi < 0)
return gsi;
} else {
diff --git a/include/kvm/irq.h b/include/kvm/irq.h
index f35eb7e..ee059e3 100644
--- a/include/kvm/irq.h
+++ b/include/kvm/irq.h
@@ -20,7 +20,7 @@ int irq__init(struct kvm *kvm);
int irq__exit(struct kvm *kvm);
int irq__allocate_routing_entry(void);
-int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg);
+int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg, u32 device_id);
void irq__update_msix_route(struct kvm *kvm, u32 gsi, struct msi_msg *msg);
#endif
diff --git a/irq.c b/irq.c
index 6ec71c3..4404062 100644
--- a/irq.c
+++ b/irq.c
@@ -66,7 +66,7 @@ static bool check_for_irq_routing(struct kvm *kvm)
return has_irq_routing > 0;
}
-int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg)
+int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg, u32 device_id)
{
int r;
@@ -77,7 +77,7 @@ int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg)
if (r)
return r;
- irq_routing->entries[irq_routing->nr++] =
+ irq_routing->entries[irq_routing->nr] =
(struct kvm_irq_routing_entry) {
.gsi = next_gsi,
.type = KVM_IRQ_ROUTING_MSI,
@@ -86,6 +86,12 @@ int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg)
.u.msi.data = msg->data,
};
+ if (kvm->msix_needs_devid) {
+ irq_routing->entries[irq_routing->nr].flags = KVM_MSI_VALID_DEVID;
+ irq_routing->entries[irq_routing->nr].u.msi.devid = device_id;
+ }
+ irq_routing->nr++;
+
r = ioctl(kvm->vm_fd, KVM_SET_GSI_ROUTING, irq_routing);
if (r)
return r;
diff --git a/virtio/pci.c b/virtio/pci.c
index f0e884c..46473b0 100644
--- a/virtio/pci.c
+++ b/virtio/pci.c
@@ -192,7 +192,8 @@ static bool virtio_pci__specific_io_out(struct kvm *kvm, struct virtio_device *v
break;
gsi = irq__add_msix_route(kvm,
- &vpci->msix_table[vec].msg);
+ &vpci->msix_table[vec].msg,
+ vpci->dev_hdr.dev_num << 3);
/*
* We don't need IRQ routing if we can use
* MSI injection via the KVM_SIGNAL_MSI ioctl.
@@ -216,7 +217,8 @@ static bool virtio_pci__specific_io_out(struct kvm *kvm, struct virtio_device *v
break;
gsi = irq__add_msix_route(kvm,
- &vpci->msix_table[vec].msg);
+ &vpci->msix_table[vec].msg,
+ vpci->dev_hdr.dev_num << 3);
/*
* We don't need IRQ routing if we can use
* MSI injection via the KVM_SIGNAL_MSI ioctl.
--
2.9.0
^ permalink raw reply related
* [kvmtool PATCH v10 13/15] arm: setup SPI IRQ routing tables
From: Andre Przywara @ 2017-04-25 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425143932.17235-1-andre.przywara@arm.com>
Since we soon start using GSI routing on ARM platforms too, we have
to setup the initial SPI routing table. Before the first call to
KVM_SET_GSI_ROUTING, the kernel holds this table internally, but this
is overwritten with the ioctl, so we have to explicitly set it up
here.
The routing is actually not used for IRQs triggered by KVM_IRQ_LINE,
but it needs to be here anyway. We use a simple 1:1 mapping.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arm/gic.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arm/gic.c b/arm/gic.c
index 651ede7..d9c3175 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -10,6 +10,8 @@
#include <linux/kvm.h>
#include <linux/sizes.h>
+#define IRQCHIP_GIC 0
+
static int gic_fd = -1;
static u64 gic_redists_base;
static u64 gic_redists_size;
@@ -32,6 +34,34 @@ int irqchip_parser(const struct option *opt, const char *arg, int unset)
return 0;
}
+static int irq__routing_init(struct kvm *kvm)
+{
+ int r;
+ int irqlines = ALIGN(irq__get_nr_allocated_lines(), 32);
+
+ /*
+ * This describes the default routing that the kernel uses without
+ * any routing explicitly set up via KVM_SET_GSI_ROUTING. So we
+ * don't need to commit these setting right now. The first actual
+ * user (MSI routing) will engage these mappings then.
+ */
+ for (next_gsi = 0; next_gsi < irqlines; next_gsi++) {
+ r = irq__allocate_routing_entry();
+ if (r)
+ return r;
+
+ irq_routing->entries[irq_routing->nr++] =
+ (struct kvm_irq_routing_entry) {
+ .gsi = next_gsi,
+ .type = KVM_IRQ_ROUTING_IRQCHIP,
+ .u.irqchip.irqchip = IRQCHIP_GIC,
+ .u.irqchip.pin = next_gsi,
+ };
+ }
+
+ return 0;
+}
+
static int gic__create_its_frame(struct kvm *kvm, u64 its_frame_addr)
{
struct kvm_create_device its_device = {
@@ -239,6 +269,8 @@ static int gic__init_gic(struct kvm *kvm)
return ret;
}
+ irq__routing_init(kvm);
+
if (!ioctl(gic_fd, KVM_HAS_DEVICE_ATTR, &vgic_init_attr)) {
ret = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, &vgic_init_attr);
if (ret)
--
2.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox