* [PATCH] ARM: dts: aspeed-g4: Correct VUART IRQ number
From: Joel Stanley @ 2017-12-15 5:33 UTC (permalink / raw)
To: linux-arm-kernel
This should have always been 8.
Fixes: db4d6d9d80fa ("ARM: dts: aspeed: Correctly order UART nodes")
Cc: stable at vger.kernel.org
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
ARM maintainers, please include this fix for 4.15
arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 45d815a86d42..de08d9045cb8 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -219,7 +219,7 @@
compatible = "aspeed,ast2400-vuart";
reg = <0x1e787000 0x40>;
reg-shift = <2>;
- interrupts = <10>;
+ interrupts = <8>;
clocks = <&clk_uart>;
no-loopback-test;
status = "disabled";
--
2.14.1
^ permalink raw reply related
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Dhaval Shah @ 2017-12-15 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7952229.SXlKMv2tvC@avalon>
Hi Laurent/Mauro/Greg,
On Fri, Dec 15, 2017 at 3:32 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Mauro,
>
> On Thursday, 14 December 2017 23:50:03 EET Mauro Carvalho Chehab wrote:
>> Em Thu, 14 Dec 2017 21:57:06 +0100 Greg KH escreveu:
>> > On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
>> >> On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
>> >>> On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
>> >>>> On Thursday, 14 December 2017 20:54:39 EET Joe Perches wrote:
>> >>>>> On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
>> >>>>>> On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
>> >>>>>>> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
>> >>>>>>>> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab
>> >>>>>>>> wrote:
>> >>>>>>>>> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
>> >>>>>>>>>> SPDX-License-Identifier is used for the Xilinx Video IP and
>> >>>>>>>>>> related drivers.
>> >>>>>>>>>>
>> >>>>>>>>>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
>> >>>>>>>>>
>> >>>>>>>>> Hi Dhaval,
>> >>>>>>>>>
>> >>>>>>>>> You're not listed as one of the Xilinx driver maintainers. I'm
>> >>>>>>>>> afraid that, without their explicit acks, sent to the ML, I
>> >>>>>>>>> can't accept a patch touching at the driver's license tags.
>> >>>>>>>>
>> >>>>>>>> The patch doesn't change the license, I don't see why it would
>> >>>>>>>> cause any issue. Greg isn't listed as the maintainer or copyright
>> >>>>>>>> holder of any of the 10k+ files to which he added an SPDX license
>> >>>>>>>> header in the last kernel release.
>> >>>>>>>
>> >>>>>>> Adding a comment line that describes an implicit or
>> >>>>>>> explicit license is different than removing the license
>> >>>>>>> text itself.
>> >>>>>>
>> >>>>>> The SPDX license header is meant to be equivalent to the license
>> >>>>>> text.
>> >>>>>
>> >>>>> I understand that.
>> >>>>> At a minimum, removing BSD license text is undesirable
>> >>>>>
>> >>>>> as that license states:
>> >>>>> * * Redistributions of source code must retain the above copyright
>> >>>>> * notice, this list of conditions and the following disclaimer.
>> >>>>>
>> >>>>> etc...
>> >>>>
>> >>>> But this patch only removes the following text:
>> >>>>
>> >>>> - * 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.
>> >>>>
>> >>>> and replaces it by the corresponding SPDX header.
>> >>>>
>> >>>>>> The only reason why the large SPDX patch didn't touch the whole
>> >>>>>> kernel in one go was that it was easier to split in in multiple
>> >>>>>> chunks.
>> >>>>>
>> >>>>> Not really, it was scripted.
>> >>>>
>> >>>> But still manually reviewed as far as I know.
>> >>>>
>> >>>>>> This is no different than not including the full GPL license in
>> >>>>>> every header file but only pointing to it through its name and
>> >>>>>> reference, as every kernel source file does.
>> >>>>>
>> >>>>> Not every kernel source file had a license text
>> >>>>> or a reference to another license file.
>> >>>>
>> >>>> Correct, but the files touched by this patch do.
>> >>>>
>> >>>> This issue is in no way specific to linux-media and should be
>> >>>> decided upon at the top level, not on a per-subsystem basis. Greg,
>> >>>> could you comment on this ?
>> >>>
>> >>> Comment on what exactly? I don't understand the problem here, care to
>> >>> summarize it?
>> >>
>> >> In a nutshell (if I understand it correctly), Dhaval Shah submitted
>> >> https:// patchwork.kernel.org/patch/10102451/ which replaces
>> >>
>> >> +// SPDX-License-Identifier: GPL-2.0
>> >> [...]
>> >> - *
>> >> - * 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.
>> >>
>> >> in all .c and .h files of the Xilinx V4L2 driver
>> >> (drivers/media/platform/
>> >> xilinx). I have reviewed the patch and acked it. Mauro then rejected it,
>> >> stating that he can't accept a change to license text without an
>> >> explicit ack from the official driver's maintainers. My position is
>> >> that such a change doesn't change the license and thus doesn't need to
>> >> track all copyright holders, and can be merged without an explicit ack
>> >> from the respective maintainers.
>> >
>> > Yes, I agree with you, no license is being changed here, and no
>> > copyright is either.
>> >
>> > BUT, I know that most major companies are reviewing this process right
>> > now. We have gotten approval from almost all of the major kernel
>> > developer companies to do this, which is great, and supports this work
>> > as being acceptable.
>> >
>> > So it's nice to ask Xilinx if they object to this happening, which I
>> > guess Mauro is trying to say here (in not so many words...) To at least
>> > give them the heads-up that this is what is going to be going on
>> > throughout the kernel tree soon, and if they object, it would be good to
>> > speak up as to why (and if they do, I can put their lawyers in contact
>> > with some lawyers to explain it all to them.)
>>
>> Yes, that's basically what I'm saying.
>>
>> I don't feel comfortable on signing a patch changing the license text
>> without giving the copyright owners an opportunity and enough time
>> to review it and approve, or otherwise comment about such changes.
>
> If I understand you and Greg correctly, you would like to get a general
> approval from Xilinx for SPDX-related changes, but that would be a blanket
> approval that would cover this and all subsequent similar patches. Is that
> correct ? That is reasonable for me.
>
> In that case, could the fact that commit
>
> commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
> Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Date: Fri Nov 3 11:28:30 2017 +0100
>
> USB: add SPDX identifiers to all remaining files in drivers/usb/
>
> add SPDX headers to several Xilinx-authored source files constitute such a
> blanket approval ?
>
I have to do anything here or Once, we get approval from the Michal
Simek(michal.simek at xilinx.com) and Hyun.kwon at xilinx.com ACK this patch
then it will go into mainline?
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* [PATCH v2 0/4] PM / OPP: Introduce ti-opp-supply driver
From: Viresh Kumar @ 2017-12-15 4:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215042528.28715-1-d-gerlach@ti.com>
On 14-12-17, 22:25, Dave Gerlach wrote:
> Hi,
> This is v2 of the series to introduce the ti-opp-supply driver which makes
> use of the OPP core to enable multiple regulator DVFS and AVS Class0 for
> TI DRA7 and AM57 platforms. Version 1 of this series can be found here [1].
>
> Very few changes since v1, just added Viresh's acks to patches 1 and 2 and
> added SPDX license to the ti-opp-supply driver in patch 4.
>
> Pushed updated branch here just in case [2].
>
> Regards,
> Dave
>
> [1] https://www.spinics.net/lists/devicetree/msg205957.html
> [2] https://github.com/dgerlach/linux-pm/tree/upstream/v4.15/ti-multireg-support-v2
>
> Dave Gerlach (4):
> cpufreq: ti-cpufreq: Convert to module_platform_driver
> cpufreq: ti-cpufreq: Add support for multiple regulators
> dt-bindings: opp: Introduce ti-opp-supply bindings
> PM / OPP: Add ti-opp-supply driver
>
> .../bindings/opp/ti-omap5-opp-supply.txt | 63 +++
> drivers/cpufreq/ti-cpufreq.c | 51 ++-
> drivers/opp/Makefile | 1 +
> drivers/opp/ti-opp-supply.c | 425 +++++++++++++++++++++
> 4 files changed, 534 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
> create mode 100644 drivers/opp/ti-opp-supply.c
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2 4/4] PM / OPP: Add ti-opp-supply driver
From: Dave Gerlach @ 2017-12-15 4:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215042528.28715-1-d-gerlach@ti.com>
Introduce a ti-opp-supply driver that will use new multiple regulator
support that is part of the OPP core This is needed on TI platforms like
DRA7/AM57 in order to control both CPU regulator and Adaptive Body Bias
(ABB) regulator. These regulators must be scaled in sequence during an
OPP transition depending on whether or not the frequency is being scaled
up or down.
This driver also implements AVS Class0 for these parts by looking up the
required values from registers in the SoC and programming adjusted
optimal voltage values for each OPP.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
drivers/opp/Makefile | 1 +
drivers/opp/ti-opp-supply.c | 425 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 426 insertions(+)
create mode 100644 drivers/opp/ti-opp-supply.c
diff --git a/drivers/opp/Makefile b/drivers/opp/Makefile
index e70ceb406fe9..6ce6aefacc81 100644
--- a/drivers/opp/Makefile
+++ b/drivers/opp/Makefile
@@ -2,3 +2,4 @@ ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
obj-y += core.o cpu.o
obj-$(CONFIG_OF) += of.o
obj-$(CONFIG_DEBUG_FS) += debugfs.o
+obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-opp-supply.o
diff --git a/drivers/opp/ti-opp-supply.c b/drivers/opp/ti-opp-supply.c
new file mode 100644
index 000000000000..44dae3e51aac
--- /dev/null
+++ b/drivers/opp/ti-opp-supply.c
@@ -0,0 +1,425 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2017 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon <nm@ti.com>
+ * Dave Gerlach <d-gerlach@ti.com>
+ *
+ * TI OPP supply driver that provides override into the regulator control
+ * for generic opp core to handle devices with ABB regulator and/or
+ * SmartReflex Class0.
+ */
+#include <linux/clk.h>
+#include <linux/cpufreq.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/notifier.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+/**
+ * struct ti_opp_supply_optimum_voltage_table - optimized voltage table
+ * @reference_uv: reference voltage (usually Nominal voltage)
+ * @optimized_uv: Optimized voltage from efuse
+ */
+struct ti_opp_supply_optimum_voltage_table {
+ unsigned int reference_uv;
+ unsigned int optimized_uv;
+};
+
+/**
+ * struct ti_opp_supply_data - OMAP specific opp supply data
+ * @vdd_table: Optimized voltage mapping table
+ * @num_vdd_table: number of entries in vdd_table
+ * @vdd_absolute_max_voltage_uv: absolute maximum voltage in UV for the supply
+ */
+struct ti_opp_supply_data {
+ struct ti_opp_supply_optimum_voltage_table *vdd_table;
+ u32 num_vdd_table;
+ u32 vdd_absolute_max_voltage_uv;
+};
+
+static struct ti_opp_supply_data opp_data;
+
+/**
+ * struct ti_opp_supply_of_data - device tree match data
+ * @flags: specific type of opp supply
+ * @efuse_voltage_mask: mask required for efuse register representing voltage
+ * @efuse_voltage_uv: Are the efuse entries in micro-volts? if not, assume
+ * milli-volts.
+ */
+struct ti_opp_supply_of_data {
+#define OPPDM_EFUSE_CLASS0_OPTIMIZED_VOLTAGE BIT(1)
+#define OPPDM_HAS_NO_ABB BIT(2)
+ const u8 flags;
+ const u32 efuse_voltage_mask;
+ const bool efuse_voltage_uv;
+};
+
+/**
+ * _store_optimized_voltages() - store optimized voltages
+ * @dev: ti opp supply device for which we need to store info
+ * @data: data specific to the device
+ *
+ * Picks up efuse based optimized voltages for VDD unique per device and
+ * stores it in internal data structure for use during transition requests.
+ *
+ * Return: If successful, 0, else appropriate error value.
+ */
+static int _store_optimized_voltages(struct device *dev,
+ struct ti_opp_supply_data *data)
+{
+ void __iomem *base;
+ struct property *prop;
+ struct resource *res;
+ const __be32 *val;
+ int proplen, i;
+ int ret = 0;
+ struct ti_opp_supply_optimum_voltage_table *table;
+ const struct ti_opp_supply_of_data *of_data = dev_get_drvdata(dev);
+
+ /* pick up Efuse based voltages */
+ res = platform_get_resource(to_platform_device(dev), IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, "Unable to get IO resource\n");
+ ret = -ENODEV;
+ goto out_map;
+ }
+
+ base = ioremap_nocache(res->start, resource_size(res));
+ if (!base) {
+ dev_err(dev, "Unable to map Efuse registers\n");
+ ret = -ENOMEM;
+ goto out_map;
+ }
+
+ /* Fetch efuse-settings. */
+ prop = of_find_property(dev->of_node, "ti,efuse-settings", NULL);
+ if (!prop) {
+ dev_err(dev, "No 'ti,efuse-settings' property found\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ proplen = prop->length / sizeof(int);
+ data->num_vdd_table = proplen / 2;
+ /* Verify for corrupted OPP entries in dt */
+ if (data->num_vdd_table * 2 * sizeof(int) != prop->length) {
+ dev_err(dev, "Invalid 'ti,efuse-settings'\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = of_property_read_u32(dev->of_node, "ti,absolute-max-voltage-uv",
+ &data->vdd_absolute_max_voltage_uv);
+ if (ret) {
+ dev_err(dev, "ti,absolute-max-voltage-uv is missing\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ table = kzalloc(sizeof(*data->vdd_table) *
+ data->num_vdd_table, GFP_KERNEL);
+ if (!table) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ data->vdd_table = table;
+
+ val = prop->value;
+ for (i = 0; i < data->num_vdd_table; i++, table++) {
+ u32 efuse_offset;
+ u32 tmp;
+
+ table->reference_uv = be32_to_cpup(val++);
+ efuse_offset = be32_to_cpup(val++);
+
+ tmp = readl(base + efuse_offset);
+ tmp &= of_data->efuse_voltage_mask;
+ tmp >>= __ffs(of_data->efuse_voltage_mask);
+
+ table->optimized_uv = of_data->efuse_voltage_uv ? tmp :
+ tmp * 1000;
+
+ dev_dbg(dev, "[%d] efuse=0x%08x volt_table=%d vset=%d\n",
+ i, efuse_offset, table->reference_uv,
+ table->optimized_uv);
+
+ /*
+ * Some older samples might not have optimized efuse
+ * Use reference voltage for those - just add debug message
+ * for them.
+ */
+ if (!table->optimized_uv) {
+ dev_dbg(dev, "[%d] efuse=0x%08x volt_table=%d:vset0\n",
+ i, efuse_offset, table->reference_uv);
+ table->optimized_uv = table->reference_uv;
+ }
+ }
+out:
+ iounmap(base);
+out_map:
+ return ret;
+}
+
+/**
+ * _free_optimized_voltages() - free resources for optvoltages
+ * @dev: device for which we need to free info
+ * @data: data specific to the device
+ */
+static void _free_optimized_voltages(struct device *dev,
+ struct ti_opp_supply_data *data)
+{
+ kfree(data->vdd_table);
+ data->vdd_table = NULL;
+ data->num_vdd_table = 0;
+}
+
+/**
+ * _get_optimal_vdd_voltage() - Finds optimal voltage for the supply
+ * @dev: device for which we need to find info
+ * @data: data specific to the device
+ * @reference_uv: reference voltage (OPP voltage) for which we need value
+ *
+ * Return: if a match is found, return optimized voltage, else return
+ * reference_uv, also return reference_uv if no optimization is needed.
+ */
+static int _get_optimal_vdd_voltage(struct device *dev,
+ struct ti_opp_supply_data *data,
+ int reference_uv)
+{
+ int i;
+ struct ti_opp_supply_optimum_voltage_table *table;
+
+ if (!data->num_vdd_table)
+ return reference_uv;
+
+ table = data->vdd_table;
+ if (!table)
+ return -EINVAL;
+
+ /* Find a exact match - this list is usually very small */
+ for (i = 0; i < data->num_vdd_table; i++, table++)
+ if (table->reference_uv == reference_uv)
+ return table->optimized_uv;
+
+ /* IF things are screwed up, we'd make a mess on console.. ratelimit */
+ dev_err_ratelimited(dev, "%s: Failed optimized voltage match for %d\n",
+ __func__, reference_uv);
+ return reference_uv;
+}
+
+static int _opp_set_voltage(struct device *dev,
+ struct dev_pm_opp_supply *supply,
+ int new_target_uv, struct regulator *reg,
+ char *reg_name)
+{
+ int ret;
+ unsigned long vdd_uv, uv_max;
+
+ if (new_target_uv)
+ vdd_uv = new_target_uv;
+ else
+ vdd_uv = supply->u_volt;
+
+ /*
+ * If we do have an absolute max voltage specified, then we should
+ * use that voltage instead to allow for cases where the voltage rails
+ * are ganged (example if we set the max for an opp as 1.12v, and
+ * the absolute max is 1.5v, for another rail to get 1.25v, it cannot
+ * be achieved if the regulator is constrainted to max of 1.12v, even
+ * if it can function at 1.25v
+ */
+ if (opp_data.vdd_absolute_max_voltage_uv)
+ uv_max = opp_data.vdd_absolute_max_voltage_uv;
+ else
+ uv_max = supply->u_volt_max;
+
+ if (vdd_uv > uv_max ||
+ vdd_uv < supply->u_volt_min ||
+ supply->u_volt_min > uv_max) {
+ dev_warn(dev,
+ "Invalid range voltages [Min:%lu target:%lu Max:%lu]\n",
+ supply->u_volt_min, vdd_uv, uv_max);
+ return -EINVAL;
+ }
+
+ dev_dbg(dev, "%s scaling to %luuV[min %luuV max %luuV]\n", reg_name,
+ vdd_uv, supply->u_volt_min,
+ uv_max);
+
+ ret = regulator_set_voltage_triplet(reg,
+ supply->u_volt_min,
+ vdd_uv,
+ uv_max);
+ if (ret) {
+ dev_err(dev, "%s failed for %luuV[min %luuV max %luuV]\n",
+ reg_name, vdd_uv, supply->u_volt_min,
+ uv_max);
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * ti_opp_supply_set_opp() - do the opp supply transition
+ * @data: information on regulators and new and old opps provided by
+ * opp core to use in transition
+ *
+ * Return: If successful, 0, else appropriate error value.
+ */
+int ti_opp_supply_set_opp(struct dev_pm_set_opp_data *data)
+{
+ struct dev_pm_opp_supply *old_supply_vdd = &data->old_opp.supplies[0];
+ struct dev_pm_opp_supply *old_supply_vbb = &data->old_opp.supplies[1];
+ struct dev_pm_opp_supply *new_supply_vdd = &data->new_opp.supplies[0];
+ struct dev_pm_opp_supply *new_supply_vbb = &data->new_opp.supplies[1];
+ struct device *dev = data->dev;
+ unsigned long old_freq = data->old_opp.rate, freq = data->new_opp.rate;
+ struct clk *clk = data->clk;
+ struct regulator *vdd_reg = data->regulators[0];
+ struct regulator *vbb_reg = data->regulators[1];
+ int vdd_uv;
+ int ret;
+
+ vdd_uv = _get_optimal_vdd_voltage(dev, &opp_data,
+ new_supply_vbb->u_volt);
+
+ /* Scaling up? Scale voltage before frequency */
+ if (freq > old_freq) {
+ ret = _opp_set_voltage(dev, new_supply_vdd, vdd_uv, vdd_reg,
+ "vdd");
+ if (ret)
+ goto restore_voltage;
+
+ ret = _opp_set_voltage(dev, new_supply_vbb, 0, vbb_reg, "vbb");
+ if (ret)
+ goto restore_voltage;
+ }
+
+ /* Change frequency */
+ dev_dbg(dev, "%s: switching OPP: %lu Hz --> %lu Hz\n",
+ __func__, old_freq, freq);
+
+ ret = clk_set_rate(clk, freq);
+ if (ret) {
+ dev_err(dev, "%s: failed to set clock rate: %d\n", __func__,
+ ret);
+ goto restore_voltage;
+ }
+
+ /* Scaling down? Scale voltage after frequency */
+ if (freq < old_freq) {
+ ret = _opp_set_voltage(dev, new_supply_vbb, 0, vbb_reg, "vbb");
+ if (ret)
+ goto restore_freq;
+
+ ret = _opp_set_voltage(dev, new_supply_vdd, vdd_uv, vdd_reg,
+ "vdd");
+ if (ret)
+ goto restore_freq;
+ }
+
+ return 0;
+
+restore_freq:
+ ret = clk_set_rate(clk, old_freq);
+ if (ret)
+ dev_err(dev, "%s: failed to restore old-freq (%lu Hz)\n",
+ __func__, old_freq);
+restore_voltage:
+ /* This shouldn't harm even if the voltages weren't updated earlier */
+ if (old_supply_vdd->u_volt) {
+ ret = _opp_set_voltage(dev, old_supply_vbb, 0, vbb_reg, "vbb");
+ if (ret)
+ return ret;
+
+ ret = _opp_set_voltage(dev, old_supply_vdd, 0, vdd_reg,
+ "vdd");
+ if (ret)
+ return ret;
+ }
+
+ return ret;
+}
+
+static const struct ti_opp_supply_of_data omap_generic_of_data = {
+};
+
+static const struct ti_opp_supply_of_data omap_omap5_of_data = {
+ .flags = OPPDM_EFUSE_CLASS0_OPTIMIZED_VOLTAGE,
+ .efuse_voltage_mask = 0xFFF,
+ .efuse_voltage_uv = false,
+};
+
+static const struct ti_opp_supply_of_data omap_omap5core_of_data = {
+ .flags = OPPDM_EFUSE_CLASS0_OPTIMIZED_VOLTAGE | OPPDM_HAS_NO_ABB,
+ .efuse_voltage_mask = 0xFFF,
+ .efuse_voltage_uv = false,
+};
+
+static const struct of_device_id ti_opp_supply_of_match[] = {
+ {.compatible = "ti,omap-opp-supply", .data = &omap_generic_of_data},
+ {.compatible = "ti,omap5-opp-supply", .data = &omap_omap5_of_data},
+ {.compatible = "ti,omap5-core-opp-supply",
+ .data = &omap_omap5core_of_data},
+ {},
+};
+MODULE_DEVICE_TABLE(of, ti_opp_supply_of_match);
+
+static int ti_opp_supply_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device *cpu_dev = get_cpu_device(0);
+ const struct of_device_id *match;
+ const struct ti_opp_supply_of_data *of_data;
+ int ret = 0;
+
+ match = of_match_device(ti_opp_supply_of_match, dev);
+ if (!match) {
+ /* We do not expect this to happen */
+ dev_err(dev, "%s: Unable to match device\n", __func__);
+ return -ENODEV;
+ }
+ if (!match->data) {
+ /* Again, unlikely.. but mistakes do happen */
+ dev_err(dev, "%s: Bad data in match\n", __func__);
+ return -EINVAL;
+ }
+ of_data = match->data;
+
+ dev_set_drvdata(dev, (void *)of_data);
+
+ /* If we need optimized voltage */
+ if (of_data->flags & OPPDM_EFUSE_CLASS0_OPTIMIZED_VOLTAGE) {
+ ret = _store_optimized_voltages(dev, &opp_data);
+ if (ret)
+ return ret;
+ }
+
+ ret = PTR_ERR_OR_ZERO(dev_pm_opp_register_set_opp_helper(cpu_dev,
+ ti_opp_supply_set_opp));
+ if (ret)
+ _free_optimized_voltages(dev, &opp_data);
+
+ return ret;
+}
+
+static struct platform_driver ti_opp_supply_driver = {
+ .probe = ti_opp_supply_probe,
+ .driver = {
+ .name = "ti_opp_supply",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ti_opp_supply_of_match),
+ },
+};
+module_platform_driver(ti_opp_supply_driver);
+
+MODULE_DESCRIPTION("Texas Instruments OMAP OPP Supply driver");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_LICENSE("GPL v2");
--
2.15.1
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: opp: Introduce ti-opp-supply bindings
From: Dave Gerlach @ 2017-12-15 4:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215042528.28715-1-d-gerlach@ti.com>
Document the devicetree bindings that describe Texas Instruments
opp-supply which allow a platform to describe multiple regulators and
additional information, such as registers containing data needed to
program aforementioned regulators.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
.../bindings/opp/ti-omap5-opp-supply.txt | 63 ++++++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
diff --git a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
new file mode 100644
index 000000000000..832346e489a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
@@ -0,0 +1,63 @@
+Texas Instruments OMAP compatible OPP supply description
+
+OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which
+contain data that can be used to adjust voltages programmed for some of their
+supplies for more efficient operation. This binding provides the information
+needed to read these values and use them to program the main regulator during
+an OPP transitions.
+
+Also, some supplies may have an associated vbb-supply which is an Adaptive Body
+Bias regulator which much be transitioned in a specific sequence with regards
+to the vdd-supply and clk when making an OPP transition. By supplying two
+regulators to the device that will undergo OPP transitions we can make use
+of the multi regulator binding that is part of the OPP core described here [1]
+to describe both regulators needed by the platform.
+
+[1] Documentation/devicetree/bindings/opp/opp.txt
+
+Required Properties for Device Node:
+- vdd-supply: phandle to regulator controlling VDD supply
+- vbb-supply: phandle to regulator controlling Body Bias supply
+ (Usually Adaptive Body Bias regulator)
+
+Required Properties for opp-supply node:
+- compatible: Should be one of:
+ "ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB
+ "ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD
+ along with VBB
+ "ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD
+ but no VBB.
+- reg: Address and length of the efuse register set for the device (mandatory
+ only for "ti,omap5-opp-supply")
+- ti,efuse-settings: An array of u32 tuple items providing information about
+ optimized efuse configuration. Each item consists of the following:
+ volt: voltage in uV - reference voltage (OPP voltage)
+ efuse_offseet: efuse offset from reg where the optimized voltage is stored.
+- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply.
+
+Example:
+
+/* Device Node (CPU) */
+cpus {
+ cpu0: cpu at 0 {
+ device_type = "cpu";
+
+ ...
+
+ vdd-supply = <&vcc>;
+ vbb-supply = <&abb_mpu>;
+ };
+};
+
+/* OMAP OPP Supply with Class0 registers */
+opp_supply_mpu: opp_supply at 4a003b20 {
+ compatible = "ti,omap5-opp-supply";
+ reg = <0x4a003b20 0x8>;
+ ti,efuse-settings = <
+ /* uV offset */
+ 1060000 0x0
+ 1160000 0x4
+ 1210000 0x8
+ >;
+ ti,absolute-max-voltage-uv = <1500000>;
+};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/4] cpufreq: ti-cpufreq: Add support for multiple regulators
From: Dave Gerlach @ 2017-12-15 4:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215042528.28715-1-d-gerlach@ti.com>
Some platforms, like those in the DRA7 and AM57 families, require the
scaling of multiple regulators in order to properly support higher OPPs.
Let the ti-cpufreq driver determine when this is required and pass the
appropriate regulator names to the OPP core so that they can be properly
managed.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index b1c230a1e2aa..a099b7bf74cd 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -51,6 +51,7 @@ struct ti_cpufreq_soc_data {
unsigned long efuse_mask;
unsigned long efuse_shift;
unsigned long rev_offset;
+ bool multi_regulator;
};
struct ti_cpufreq_data {
@@ -58,6 +59,7 @@ struct ti_cpufreq_data {
struct device_node *opp_node;
struct regmap *syscon;
const struct ti_cpufreq_soc_data *soc_data;
+ struct opp_table *opp_table;
};
static unsigned long amx3_efuse_xlate(struct ti_cpufreq_data *opp_data,
@@ -96,6 +98,7 @@ static struct ti_cpufreq_soc_data am3x_soc_data = {
.efuse_offset = 0x07fc,
.efuse_mask = 0x1fff,
.rev_offset = 0x600,
+ .multi_regulator = false,
};
static struct ti_cpufreq_soc_data am4x_soc_data = {
@@ -104,6 +107,7 @@ static struct ti_cpufreq_soc_data am4x_soc_data = {
.efuse_offset = 0x0610,
.efuse_mask = 0x3f,
.rev_offset = 0x600,
+ .multi_regulator = false,
};
static struct ti_cpufreq_soc_data dra7_soc_data = {
@@ -112,6 +116,7 @@ static struct ti_cpufreq_soc_data dra7_soc_data = {
.efuse_mask = 0xf80000,
.efuse_shift = 19,
.rev_offset = 0x204,
+ .multi_regulator = true,
};
/**
@@ -201,7 +206,9 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
u32 version[VERSION_COUNT];
struct device_node *np;
const struct of_device_id *match;
+ struct opp_table *ti_opp_table;
struct ti_cpufreq_data *opp_data;
+ const char * const reg_names[] = {"vdd", "vbb"};
int ret;
np = of_find_node_by_path("/");
@@ -248,16 +255,29 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
if (ret)
goto fail_put_node;
- ret = PTR_ERR_OR_ZERO(dev_pm_opp_set_supported_hw(opp_data->cpu_dev,
- version, VERSION_COUNT));
- if (ret) {
+ ti_opp_table = dev_pm_opp_set_supported_hw(opp_data->cpu_dev,
+ version, VERSION_COUNT);
+ if (IS_ERR(ti_opp_table)) {
dev_err(opp_data->cpu_dev,
"Failed to set supported hardware\n");
+ ret = PTR_ERR(ti_opp_table);
goto fail_put_node;
}
- of_node_put(opp_data->opp_node);
+ opp_data->opp_table = ti_opp_table;
+
+ if (opp_data->soc_data->multi_regulator) {
+ ti_opp_table = dev_pm_opp_set_regulators(opp_data->cpu_dev,
+ reg_names,
+ ARRAY_SIZE(reg_names));
+ if (IS_ERR(ti_opp_table)) {
+ dev_pm_opp_put_supported_hw(opp_data->opp_table);
+ ret = PTR_ERR(ti_opp_table);
+ goto fail_put_node;
+ }
+ }
+ of_node_put(opp_data->opp_node);
register_cpufreq_dt:
platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
--
2.15.1
^ permalink raw reply related
* [PATCH v2 1/4] cpufreq: ti-cpufreq: Convert to module_platform_driver
From: Dave Gerlach @ 2017-12-15 4:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215042528.28715-1-d-gerlach@ti.com>
ti-cpufreq will be responsible for calling dev_pm_opp_set_regulators on
platforms that require AVS and ABB regulator support so we must be
able to defer probe if regulators are not yet available, so change
ti-cpufreq to be a module_platform_driver to allow for probe defer.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 923317f03b4b..b1c230a1e2aa 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -17,6 +17,7 @@
#include <linux/cpu.h>
#include <linux/io.h>
#include <linux/mfd/syscon.h>
+#include <linux/module.h>
#include <linux/init.h>
#include <linux/of.h>
#include <linux/of_platform.h>
@@ -195,7 +196,7 @@ static const struct of_device_id ti_cpufreq_of_match[] = {
{},
};
-static int ti_cpufreq_init(void)
+static int ti_cpufreq_probe(struct platform_device *pdev)
{
u32 version[VERSION_COUNT];
struct device_node *np;
@@ -269,4 +270,22 @@ static int ti_cpufreq_init(void)
return ret;
}
-device_initcall(ti_cpufreq_init);
+
+static int ti_cpufreq_init(void)
+{
+ platform_device_register_simple("ti-cpufreq", -1, NULL, 0);
+ return 0;
+}
+module_init(ti_cpufreq_init);
+
+static struct platform_driver ti_cpufreq_driver = {
+ .probe = ti_cpufreq_probe,
+ .driver = {
+ .name = "ti-cpufreq",
+ },
+};
+module_platform_driver(ti_cpufreq_driver);
+
+MODULE_DESCRIPTION("TI CPUFreq/OPP hw-supported driver");
+MODULE_AUTHOR("Dave Gerlach <d-gerlach@ti.com>");
+MODULE_LICENSE("GPL v2");
--
2.15.1
^ permalink raw reply related
* [PATCH v2 0/4] PM / OPP: Introduce ti-opp-supply driver
From: Dave Gerlach @ 2017-12-15 4:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v2 of the series to introduce the ti-opp-supply driver which makes
use of the OPP core to enable multiple regulator DVFS and AVS Class0 for
TI DRA7 and AM57 platforms. Version 1 of this series can be found here [1].
Very few changes since v1, just added Viresh's acks to patches 1 and 2 and
added SPDX license to the ti-opp-supply driver in patch 4.
Pushed updated branch here just in case [2].
Regards,
Dave
[1] https://www.spinics.net/lists/devicetree/msg205957.html
[2] https://github.com/dgerlach/linux-pm/tree/upstream/v4.15/ti-multireg-support-v2
Dave Gerlach (4):
cpufreq: ti-cpufreq: Convert to module_platform_driver
cpufreq: ti-cpufreq: Add support for multiple regulators
dt-bindings: opp: Introduce ti-opp-supply bindings
PM / OPP: Add ti-opp-supply driver
.../bindings/opp/ti-omap5-opp-supply.txt | 63 +++
drivers/cpufreq/ti-cpufreq.c | 51 ++-
drivers/opp/Makefile | 1 +
drivers/opp/ti-opp-supply.c | 425 +++++++++++++++++++++
4 files changed, 534 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
create mode 100644 drivers/opp/ti-opp-supply.c
--
2.15.1
^ permalink raw reply
* [PATCH] arm: dts: Remove leading 0x and 0s from bindings notation
From: Viresh Kumar @ 2017-12-15 4:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214165350.27850-1-malat@debian.org>
On 14-12-17, 17:53, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/arm/boot/dts/spear300.dtsi | 2 +-
> arch/arm/boot/dts/spear310.dtsi | 2 +-
> arch/arm/boot/dts/spear320.dtsi | 2 +-
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH V6 02/13] of: platform: Make of_platform_bus_create() global
From: Viresh Kumar @ 2017-12-15 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3875af7e7e77745f02ad429f09a1ad168a55e248.1513264961.git.viresh.kumar@linaro.org>
The boot constraints core needs to create platform or AMBA devices
corresponding to a compatible string and not for rest of the nodes in
DT. of_platform_bus_create() fits in the best to achieve that.
Allow it to be used outside of platform.c.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V6:
- Build bot reported a compilation error when CONFIG_OF_ADDRESS isn't
selected in .config.
- Git didn't catch the change in the file when I rebased the patches to
the latest kernel and applied this patch cleanly and so I missed that
the function declaration is placed outside of the #ifdef/endif block.
- This patch just moves the declaration within the CONFIG_OF_ADDRESS
block.
drivers/of/platform.c | 8 ++++----
include/linux/of_platform.h | 11 +++++++++++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 61a4a81bea9f..6f707bfb348f 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -397,10 +397,10 @@ static const struct of_dev_auxdata *of_dev_lookup(const struct of_dev_auxdata *l
* Creates a platform_device for the provided device_node, and optionally
* recursively create devices for all the child nodes.
*/
-static int of_platform_bus_create(struct device_node *bus,
- const struct of_device_id *matches,
- const struct of_dev_auxdata *lookup,
- struct device *parent, bool strict)
+int of_platform_bus_create(struct device_node *bus,
+ const struct of_device_id *matches,
+ const struct of_dev_auxdata *lookup,
+ struct device *parent, bool strict)
{
const struct of_dev_auxdata *auxdata;
struct device_node *child;
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 4909d1aa47ec..ff80fba79c41 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -81,6 +81,10 @@ extern int of_platform_bus_probe(struct device_node *root,
const struct of_device_id *matches,
struct device *parent);
#ifdef CONFIG_OF_ADDRESS
+extern int of_platform_bus_create(struct device_node *bus,
+ const struct of_device_id *matches,
+ const struct of_dev_auxdata *lookup,
+ struct device *parent, bool strict);
extern int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
@@ -94,6 +98,13 @@ extern int devm_of_platform_populate(struct device *dev);
extern void devm_of_platform_depopulate(struct device *dev);
#else
+static inline int of_platform_bus_create(struct device_node *bus,
+ const struct of_device_id *matches,
+ const struct of_dev_auxdata *lookup,
+ struct device *parent, bool strict)
+{
+ return -ENODEV;
+}
static inline int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH] arm64: allwinner: a64: a64-olinuxino: add usb otg
From: kbuild test robot @ 2017-12-15 3:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513058169-25516-1-git-send-email-jagan@amarulasolutions.com>
Hi Jagan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.15-rc3]
[cannot apply to next-20171214]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jagan-Teki/arm64-allwinner-a64-a64-olinuxino-add-usb-otg/20171215-084728
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts:204.1-15 Label or path reg_drivevbus not found
>> FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37312 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/86724236/attachment-0001.gz>
^ permalink raw reply
* [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
From: gengdongjiu @ 2017-12-15 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b37e86d-eee3-c51e-eceb-5d0c7ad12886@huawei.com>
Hi James,
On 2017/12/7 14:37, gengdongjiu wrote:
>> We need to tackle (1) and (3) separately. For (3) we need some API that lets
>> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't have
>> a way of migrating pending SError yet... which is where I got stuck last time I
>> was looking at this.
> I understand you most idea.
>
> But In the Qemu one signal type can only correspond to one behavior, can not correspond to two behaviors,
> otherwise Qemu will do not know how to do.
>
> For the Qemu, if it receives the SIGBUS_MCEERR_AR signal, it will populate the CPER
> records and inject a SEA to guest through KVM IOCTL "KVM_SET_ONE_REG"; if receives the SIGBUS_MCEERR_AO
> signal, it will record the CPER and trigger a IRQ to notify guest, as shown below:
>
> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
> SIGBUS_MCEERR_AO trigger GPIO IRQ.
>
> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify trigger method, which all
>
> not involve _trigger_ an SError.
>
> so there is no chance for Qemu to trigger the SError when gets the SIGBUS_MCEERR_A{O,R}.
As I explained above:
If Qemu received SIGBUS_MCEERR_AR, it will record CPER and trigger Synchronous External Abort;
If Qemu received SIGBUS_MCEERR_AO, it will record CPER and trigger GPIO IRQ;
So Qemu does not know when to _trigger_ an SError.
so here I "return a error" to Qemu if ghes_notify_sei() return failure in [1], if you opposed KVM "return error",
do you have a better idea about it? thanks
About the way of migrating pending SError, I think it is a separate case, because Qemu still does not know
how and when to trigger the SError.
[1]:
static int kvm_handle_guest_sei(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
.......................
+ case ESR_ELx_AET_UER: /* The error has not been propagated */
+ /*
+ * Userspace only handle the guest SError Interrupt(SEI) if the
+ * error has not been propagated
+ */
+ run->exit_reason = KVM_EXIT_EXCEPTION;
+ run->ex.exception = ESR_ELx_EC_SERROR;
+ run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
+ return 0;
.......................
}
>
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC
From: Yixun Lan @ 2017-12-15 2:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Jian Hu <jian.hu@amlogic.com>
Add PWM DT info for the Amlogic's Meson-Axg SoC.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
Changes in v2 since [1]
- drop clock DT info from soc.dtsi
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005578.html
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 112 +++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index a0d7b10da512..1ee5f12115b6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -120,6 +120,20 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
+ pwm_ab: pwm at 1b000 {
+ compatible = "amlogic,meson-axg-ee-pwm";
+ reg = <0x0 0x1b000 0x0 0x20>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_cd: pwm at 1a000 {
+ compatible = "amlogic,meson-axg-ee-pwm";
+ reg = <0x0 0x1a000 0x0 0x20>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
uart_A: serial at 24000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
@@ -180,6 +194,90 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_periphs 0 0 86>;
};
+
+ pwm_a_a_pins: pwm_a_a {
+ mux {
+ groups = "pwm_a_a";
+ function = "pwm_a";
+ };
+ };
+
+ pwm_a_x18_pins: pwm_a_x18 {
+ mux {
+ groups = "pwm_a_x18";
+ function = "pwm_a";
+ };
+ };
+
+ pwm_a_x20_pins: pwm_a_x20 {
+ mux {
+ groups = "pwm_a_x20";
+ function = "pwm_a";
+ };
+ };
+
+ pwm_a_z_pins: pwm_a_z {
+ mux {
+ groups = "pwm_a_z";
+ function = "pwm_a";
+ };
+ };
+
+ pwm_b_a_pins: pwm_b_a {
+ mux {
+ groups = "pwm_b_a";
+ function = "pwm_b";
+ };
+ };
+
+ pwm_b_x_pins: pwm_b_x {
+ mux {
+ groups = "pwm_b_x";
+ function = "pwm_b";
+ };
+ };
+
+ pwm_b_z_pins: pwm_b_z {
+ mux {
+ groups = "pwm_b_z";
+ function = "pwm_b";
+ };
+ };
+
+ pwm_c_a_pins: pwm_c_a {
+ mux {
+ groups = "pwm_c_a";
+ function = "pwm_c";
+ };
+ };
+
+ pwm_c_x10_pins: pwm_c_x10 {
+ mux {
+ groups = "pwm_c_x10";
+ function = "pwm_c";
+ };
+ };
+
+ pwm_c_x17_pins: pwm_c_x17 {
+ mux {
+ groups = "pwm_c_x17";
+ function = "pwm_c";
+ };
+ };
+
+ pwm_d_x11_pins: pwm_d_x11 {
+ mux {
+ groups = "pwm_d_x11";
+ function = "pwm_d";
+ };
+ };
+
+ pwm_d_x16_pins: pwm_d_x16 {
+ mux {
+ groups = "pwm_d_x16";
+ function = "pwm_d";
+ };
+ };
};
};
@@ -225,6 +323,20 @@
};
};
+ pwm_AO_ab: pwm at 7000 {
+ compatible = "amlogic,meson-axg-ao-pwm";
+ reg = <0x0 0x07000 0x0 0x20>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_AO_cd: pwm at 2000 {
+ compatible = "amlogic,axg-ao-pwm";
+ reg = <0x0 0x02000 0x0 0x20>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
uart_AO: serial at 3000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
reg = <0x0 0x3000 0x0 0x18>;
--
2.15.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6sx-sdb: Disable PCI support
From: Fabio Estevam @ 2017-12-15 2:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513271667-1960-1-git-send-email-festevam@gmail.com>
Hi Shawn,
On Thu, Dec 14, 2017 at 3:14 PM, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> When I added PCI support for this board I was testing with mainline U-Boot,
> which has PCI support and enables the i.mx6sx PCI power domain.
>
> When running on a U-Boot without PCI support, such as the one provided
> by NXP a kernel hang is observed.
>
> Better to disable the pci node for now, until the i.MX6SX PCI power domain
> is properly implemented in the kernel.
Just sent two patches that add i.MX6SX PCI power domain support.
If they are accepted then this one can be discarded.
Patch 2/2 of this series should still be applied though.
Thanks
^ permalink raw reply
* [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler
From: Jia He @ 2017-12-15 2:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214154518.GX910@cbox>
On 12/14/2017 11:45 PM, Christoffer Dall Wrote:
> On Thu, Dec 14, 2017 at 11:28:04PM +0800, Jia He wrote:
>> On 12/14/2017 9:09 PM, Christoffer Dall Wrote:
>>> On Thu, Dec 14, 2017 at 12:57:54PM +0800, Jia He wrote:
>>> Hi Jia,
>>>
>>>> I have tried your newer level-mapped-v7 branch, but bug is still there.
>>>>
>>>> There is no special load in both host and guest. The guest (kernel
>>>> 4.14) is often hanging when booting
>>>>
>>>> the guest kernel log
>>>>
>>>> [ OK ] Reached target Remote File Systems.
>>>> Starting File System Check on /dev/mapper/fedora-root...
>>>> [ OK ] Started File System Check on /dev/mapper/fedora-root.
>>>> Mounting /sysroot...
>>>> [ 2.670764] SGI XFS with ACLs, security attributes, no debug enabled
>>>> [ 2.678180] XFS (dm-0): Mounting V5 Filesystem
>>>> [ 2.740364] XFS (dm-0): Ending clean mount
>>>> [ OK ] Mounted /sysroot.
>>>> [ OK ] Reached target Initrd Root File System.
>>>> Starting Reload Configuration from the Real Root...
>>>> [ 61.288215] INFO: rcu_sched detected stalls on CPUs/tasks:
>>>> [ 61.290791] 1-...!: (0 ticks this GP) idle=574/0/0 softirq=5/5 fqs=1
>>>> [ 61.293664] (detected by 0, t=6002 jiffies, g=-263, c=-264, q=39760)
>>>> [ 61.296480] Task dump for CPU 1:
>>>> [ 61.297938] swapper/1 R running task 0 0 1 0x00000020
>>>> [ 61.300643] Call trace:
>>>> [ 61.301260] __switch_to+0x6c/0x78
>>>> [ 61.302095] cpu_number+0x0/0x8
>>>> [ 61.302867] rcu_sched kthread starved for 6000 jiffies!
>>>> g18446744073709551353 c18446744073709551352 f0x0 RCU_GP_WAIT_FQS(3)
>>>> ->state=0x402 ->cpu=1
>>>> [ 61.305941] rcu_sched I 0 8 2 0x00000020
>>>> [ 61.307250] Call trace:
>>>> [ 61.307854] __switch_to+0x6c/0x78
>>>> [ 61.308693] __schedule+0x268/0x8f0
>>>> [ 61.309545] schedule+0x2c/0x88
>>>> [ 61.310325] schedule_timeout+0x84/0x3b8
>>>> [ 61.311278] rcu_gp_kthread+0x4d4/0x7d8
>>>> [ 61.312213] kthread+0x134/0x138
>>>> [ 61.313001] ret_from_fork+0x10/0x1c
>>>>
>>>> Maybe my previous patch is not perfect enough, thanks for your comments.
>>>>
>>>> I digged it futher more, do you think below code logic is possibly
>>>> problematic?
>>>>
>>>>
>>>> vtimer_save_state?????????? (vtimer->loaded = false, cntv_ctl is 0)
>>>>
>>>> kvm_arch_timer_handler????????(read cntv_ctl and set vtimer->cnt_ctl = 0)
>>>>
>>>> vtimer_restore_state ? ? ? ? ?? (write vtimer->cnt_ctl to cntv_ctl,
>>>> then cntv_ctl will
>>>>
>>>> ??? ??? ??? ??? ?? ? ? be 0 forever)
>>>>
>>>>
>>>> If above analysis is reasonable
>>> Yes, I think there's something there if the hardware doesn't retire the
>>> signal fast enough...
>>>
>>>> how about below patch? already
>>>> tested in my arm64 server.
>>>>
>>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>>> index f9555b1..ee6dd3f 100644
>>>> --- a/virt/kvm/arm/arch_timer.c
>>>> +++ b/virt/kvm/arm/arch_timer.c
>>>> @@ -99,7 +99,7 @@ static irqreturn_t kvm_arch_timer_handler(int irq,
>>>> void *dev_id)
>>>> ??????? }
>>>> ??????? vtimer = vcpu_vtimer(vcpu);
>>>>
>>>> -?????? if (!vtimer->irq.level) {
>>>> +?????? if (vtimer->loaded && !vtimer->irq.level) {
>>>> ??????????????? vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
>>>> ??????????????? if (kvm_timer_irq_can_fire(vtimer))
>>>> ??????????????????????? kvm_timer_update_irq(vcpu, true, vtimer);
>>>>
>>> There's nothing really wrong with that patch, I just didn't think it
>>> would be necessary, as we really shouldn't see interrupts if the timer
>>> is not loaded. Can you confirm that a WARN_ON(!vtimer->loaded) in
>>> kvm_arch_timer_handler() gives you a splat?
>> Please see the WARN_ON result (without my patch)
>> [?? 72.171706] WARNING: CPU: 24 PID: 1768 at
>> arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:101
>> kvm_arch_timer_handler+0xc0/0xc8
>>
>>> Also, could you give the following a try (without your patch):
>>>
>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>> index 73d262c4712b..4751255345d1 100644
>>> --- a/virt/kvm/arm/arch_timer.c
>>> +++ b/virt/kvm/arm/arch_timer.c
>>> @@ -367,6 +367,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
>>> /* Disable the virtual timer */
>>> write_sysreg_el0(0, cntv_ctl);
>>> + isb();
>> No luck? the bug is still there
>>
> ok, so this is a slightly different approach to what you were trying to
> do. Can you please give this a try and let me know how it goes?
>
This patch fixes the bug in our platform.
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 73d262c4712b..544ed15fbbb3 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -46,7 +46,7 @@ static const struct kvm_irq_level default_vtimer_irq = {
> .level = 1,
> };
>
> -static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx);
> +static bool kvm_timer_irq_can_fire(u32 cnt_ctl);
> static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
> struct arch_timer_context *timer_ctx);
> static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx);
> @@ -94,6 +94,7 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> {
> struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
> struct arch_timer_context *vtimer;
> + u32 cnt_ctl;
>
> if (!vcpu) {
> pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
> @@ -101,8 +102,8 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> }
> vtimer = vcpu_vtimer(vcpu);
>
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - if (kvm_timer_irq_can_fire(vtimer))
> + cnt_ctl = read_sysreg_el0(cntv_ctl);
> + if (kvm_timer_irq_can_fire(cnt_ctl))
> kvm_timer_update_irq(vcpu, true, vtimer);
IIUC, your patch makes kvm_arch_timer_handler never changesvtimer->cnt_ctl
>
> if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
> @@ -148,10 +149,10 @@ static u64 kvm_timer_compute_delta(struct arch_timer_context *timer_ctx)
> return 0;
> }
>
> -static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx)
> +static bool kvm_timer_irq_can_fire(u32 cnt_ctl)
> {
> - return !(timer_ctx->cnt_ctl & ARCH_TIMER_CTRL_IT_MASK) &&
> - (timer_ctx->cnt_ctl & ARCH_TIMER_CTRL_ENABLE);
> + return !(cnt_ctl & ARCH_TIMER_CTRL_IT_MASK) &&
> + (cnt_ctl & ARCH_TIMER_CTRL_ENABLE);
> }
>
> /*
> @@ -164,10 +165,10 @@ static u64 kvm_timer_earliest_exp(struct kvm_vcpu *vcpu)
> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>
> - if (kvm_timer_irq_can_fire(vtimer))
> + if (kvm_timer_irq_can_fire(vtimer->cnt_ctl))
> min_virt = kvm_timer_compute_delta(vtimer);
>
> - if (kvm_timer_irq_can_fire(ptimer))
> + if (kvm_timer_irq_can_fire(ptimer->cnt_ctl))
> min_phys = kvm_timer_compute_delta(ptimer);
>
> /* If none of timers can fire, then return 0 */
> @@ -231,7 +232,7 @@ static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx)
> {
> u64 cval, now;
>
> - if (!kvm_timer_irq_can_fire(timer_ctx))
> + if (!kvm_timer_irq_can_fire(timer_ctx->cnt_ctl))
> return false;
>
> cval = timer_ctx->cnt_cval;
> @@ -306,7 +307,7 @@ static void phys_timer_emulate(struct kvm_vcpu *vcpu)
> * don't need to have a soft timer scheduled for the future. If the
> * timer cannot fire at all, then we also don't need a soft timer.
> */
> - if (kvm_timer_should_fire(ptimer) || !kvm_timer_irq_can_fire(ptimer)) {
> + if (kvm_timer_should_fire(ptimer) || !kvm_timer_irq_can_fire(ptimer->cnt_ctl)) {
> soft_timer_cancel(&timer->phys_timer, NULL);
> return;
> }
> @@ -367,6 +368,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
>
> /* Disable the virtual timer */
> write_sysreg_el0(0, cntv_ctl);
> + isb();
My only concern is whether this isb() is required here?
Sorryif this is a stupid question.I understand little about arm arch
memory barrier. But seems isb will flush all the instruction prefetch.Do
you think if an timer interrupt irq arrives, arm will use the previous
instruction prefetch?
Cheers,
Jia
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6sx: Add support for PCI power domain
From: Fabio Estevam @ 2017-12-15 2:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513304698-15169-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Previously PCI support was working because the bootloader has previously
powered up the PCI power domain.
Represent the PCI power domain, so that PCI is functional without
relying on the PCI support from the bootloader.
Tested on a imx6sx-sdb board with no PCI support in the bootloader.
Reported-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6sx.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 40c6738c..c6ea6ec 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -750,6 +750,19 @@
#interrupt-cells = <3>;
interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&intc>;
+ clocks = <&clks IMX6SX_CLK_IPG>;
+ clock-names = "ipg";
+
+ pgc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pd_pci: power-domain at 3 {
+ reg = <3>;
+ #power-domain-cells = <0>;
+ power-supply = <®_pcie>;
+ };
+ };
};
iomuxc: iomuxc at 20e0000 {
@@ -1328,6 +1341,7 @@
<&clks IMX6SX_CLK_PCIE_REF_125M>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_inbound_axi";
+ power-domains = <&pd_pci>;
status = "disabled";
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] soc: imx: gpc: Add i.MX6SX PCI power domain
From: Fabio Estevam @ 2017-12-15 2:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
i.MX6SX has a PCI power domain in PGC. Add support for it.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Documentation/devicetree/bindings/power/fsl,imx-gpc.txt | 3 +++
drivers/soc/imx/gpc.c | 16 +++++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
index e371b26..441f71e 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
@@ -9,6 +9,7 @@ Required properties:
- fsl,imx6q-gpc
- fsl,imx6qp-gpc
- fsl,imx6sl-gpc
+ - fsl,imx6sx-gpc
- reg: should be register base and length as documented in the
datasheet
- interrupts: Should contain one interrupt specifier for the GPC interrupt
@@ -29,6 +30,8 @@ Required properties:
PU_DOMAIN 1
The following additional DOMAIN_INDEX value is valid for i.MX6SL:
DISPLAY_DOMAIN 2
+ The following additional DOMAIN_INDEX value is valid for i.MX6SX:
+ PCI_DOMAIN 3
- #power-domain-cells: Should be 0
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 47e7aa9..53f7275 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -273,7 +273,15 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x240,
.cntr_pdn_bit = 4,
- }
+ }, {
+ .base = {
+ .name = "PCI",
+ .power_off = imx6_pm_domain_power_off,
+ .power_on = imx6_pm_domain_power_on,
+ },
+ .reg_offs = 0x200,
+ .cntr_pdn_bit = 6,
+ },
};
struct imx_gpc_dt_data {
@@ -296,10 +304,16 @@ static const struct imx_gpc_dt_data imx6sl_dt_data = {
.err009619_present = false,
};
+static const struct imx_gpc_dt_data imx6sx_dt_data = {
+ .num_domains = 4,
+ .err009619_present = false,
+};
+
static const struct of_device_id imx_gpc_dt_ids[] = {
{ .compatible = "fsl,imx6q-gpc", .data = &imx6q_dt_data },
{ .compatible = "fsl,imx6qp-gpc", .data = &imx6qp_dt_data },
{ .compatible = "fsl,imx6sl-gpc", .data = &imx6sl_dt_data },
+ { .compatible = "fsl,imx6sx-gpc", .data = &imx6sx_dt_data },
{ }
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/2] ARM64: dts: meson-axg: enable ethernet for A113D S400 board
From: Yixun Lan @ 2017-12-15 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215021014.231308-1-yixun.lan@amlogic.com>
This is tested in the S400 dev board which use a RTL8211F PHY,
and the pins connect to the 'eth_rgmii_y_pins' group.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..b8c4f1913d28 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -20,3 +20,10 @@
&uart_AO {
status = "okay";
};
+
+ðmac {
+ status = "okay";
+ phy-mode = "rgmii";
+ pinctrl-0 = <ð_rgmii_y_pins>;
+ pinctrl-names = "default";
+};
--
2.15.1
^ permalink raw reply related
* [PATCH v3 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-15 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215021014.231308-1-yixun.lan@amlogic.com>
Add DT info for the stmmac ethernet MAC which found in
the Amlogic's Meson-AXG SoC, also describe the ethernet
pinctrl & clock information here.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d356ce74ad89..94c4972222b7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axg-clkc.h>
/ {
compatible = "amlogic,meson-axg";
@@ -148,6 +149,19 @@
#address-cells = <0>;
};
+ ethmac: ethernet at ff3f0000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0x0 0xff3f0000 0x0 0x10000
+ 0x0 0xff634540 0x0 0x8>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "macirq";
+ clocks = <&clkc CLKID_ETH>,
+ <&clkc CLKID_FCLK_DIV2>,
+ <&clkc CLKID_MPLL2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ status = "disabled";
+ };
+
hiubus: bus at ff63c000 {
compatible = "simple-bus";
reg = <0x0 0xff63c000 0x0 0x1c00>;
@@ -194,6 +208,46 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_periphs 0 0 86>;
};
+
+ eth_rgmii_x_pins: eth-x-rgmii {
+ mux {
+ groups = "eth_mdio_x",
+ "eth_mdc_x",
+ "eth_rgmii_rx_clk_x",
+ "eth_rx_dv_x",
+ "eth_rxd0_x",
+ "eth_rxd1_x",
+ "eth_rxd2_rgmii",
+ "eth_rxd3_rgmii",
+ "eth_rgmii_tx_clk",
+ "eth_txen_x",
+ "eth_txd0_x",
+ "eth_txd1_x",
+ "eth_txd2_rgmii",
+ "eth_txd3_rgmii";
+ function = "eth";
+ };
+ };
+
+ eth_rgmii_y_pins: eth-y-rgmii {
+ mux {
+ groups = "eth_mdio_y",
+ "eth_mdc_y",
+ "eth_rgmii_rx_clk_y",
+ "eth_rx_dv_y",
+ "eth_rxd0_y",
+ "eth_rxd1_y",
+ "eth_rxd2_rgmii",
+ "eth_rxd3_rgmii",
+ "eth_rgmii_tx_clk",
+ "eth_txen_y",
+ "eth_txd0_y",
+ "eth_txd1_y",
+ "eth_txd2_rgmii",
+ "eth_txd3_rgmii";
+ function = "eth";
+ };
+ };
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH v3 0/2] Add ethernet support for Meson-AXG SoC
From: Yixun Lan @ 2017-12-15 2:10 UTC (permalink / raw)
To: linux-arm-kernel
This series try to add support for the ethernet MAC controller
found in Meson-AXG SoC, and also enable it in the S400 board.
Changes in v3 since [4]:
- put clock DT info in soc.dtsi
- separate DT for 'add support for the controller' vs 'enable in board'
Changes in v2 since [1]:
- rebase to kevin's v4.16/dt64 branch
- add Neil's Reviewed-by
- move clock info to board.dts instead of in soc.dtsi
- drop "meson-axg-dwmac" compatible string, since we didn't use this
we could re-add it later when we really need.
- note: to make ethernet work properly,it depend on clock & pinctrl[2],
to compile the DTS, the patch [3] is required.
the code part will be taken via clock & pinctrl subsystem tree.
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005301.html
[4]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005768.html
[2]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005735.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005694.html
[3]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005738.html
Yixun Lan (2):
ARM64: dts: meson-axg: add ethernet mac controller
ARM64: dts: meson-axg: enable ethernet for A113D S400 board
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
--
2.15.1
^ permalink raw reply
* [PATCH v7 6/6] arm64: dts: meson-axg: switch uart_ao clock to CLK81
From: Yixun Lan @ 2017-12-15 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513270051.2261.11.camel@baylibre.com>
On 12/15/17 00:47, Jerome Brunet wrote:
> On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote:
>> Switch the uart_ao pclk to CLK81 since the clock driver is ready.
>> Also move the clock info to the board.dts instead in the soc.dtsi.
>
> Same comment as for ethmac, is it really wise ?
> Isn't the clock setup the same for the axg family ?
>
HI Jerome:
yes, should be same for AXG family
HI Kevin:
could you take the patch [5/6]? then I just need to resend for this one
Yixun
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-15 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513269947.2261.9.camel@baylibre.com>
Hi Jerome:
On 12/15/17 00:45, Jerome Brunet wrote:
> On Thu, 2017-12-14 at 11:02 +0800, Yixun Lan wrote:
>> ---
>> Changes in v2 since [1]:
>> - rebase to kevin's v4.16/dt64 branch
>> - add Neil's Reviewed-by
>> - move clock info to board.dts instead of in soc.dtsi
>
> You got this comment regarding the pwm clock setup. the setup of the pwm clocks
> depends on the use case, so should defined depending on the requirement on the
> board
>
Yes, I thought it was a convention to put the clock into board.dts ..
I think it's more clear if you could have a three level hierarchy:
arch.dtsi. soc.dtsi, board.dts
most of clock and pinctrl could go to soc.dtsi
> This is not the case for the ethmac, the clock setup will be same for every
> board, unless I missed something. the clock bindings should be defined in
> meson-axg.dtsi, I think
>
yes, clock should be same
I will send another series to fix this
also will fold the DT separation (for soc.dtsi vs board.dts)
>> - drop "meson-axg-dwmac" compatible string, since we didn't use this
>> we could re-add it later when we really need.
>> - note: to make ethernet work properly,it depend on clock & pinctrl[2],
>> to compile the DTS, the patch [3] is required.
>> the code part will be taken via clock & pinctrl subsystem tree.
>
> .
>
^ permalink raw reply
* [patch v14 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
From: Joel Stanley @ 2017-12-15 1:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513268971-13518-3-git-send-email-oleksandrs@mellanox.com>
On Fri, Dec 15, 2017 at 2:59 AM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.
Looks good. I have a few small things below, but I am happy to see
this merged from my point of view as ASPEED maintainer.
Cheers,
Joel
> +
> +menuconfig JTAG_ASPEED
> + tristate "Aspeed SoC JTAG controller support"
> + depends on JTAG && HAS_IOMEM
Add ARCH_ASPEED || COMPILE_TEST
> + ---help---
> + This provides a support for Aspeed JTAG device, equipped on
> + Aspeed SoC 24xx and 25xx families. Drivers allows programming
> + of hardware devices, connected to SoC through the JTAG interface.
> +
> + If you want this support, you should say Y here.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called jtag-aspeed.
> diff --git a/drivers/jtag/Makefile b/drivers/jtag/Makefile
> index af37493..04a855e 100644
> --- a/drivers/jtag/Makefile
> +++ b/drivers/jtag/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_JTAG) += jtag.o
> +obj-$(CONFIG_JTAG_ASPEED) += jtag-aspeed.o
> diff --git a/drivers/jtag/jtag-aspeed.c b/drivers/jtag/jtag-aspeed.c
> new file mode 100644
> index 0000000..99277d2
> --- /dev/null
> +++ b/drivers/jtag/jtag-aspeed.c
> @@ -0,0 +1,783 @@
> +static int aspeed_jtag_xfer(struct jtag *jtag, struct jtag_xfer *xfer,
> + u8 *xfer_data)
> +{
> + static const u8 sm_update_shiftir[] = {1, 1, 0, 0};
> + static const u8 sm_update_shiftdr[] = {1, 0, 0};
> + static const u8 sm_pause_idle[] = {1, 1, 0};
> + static const u8 sm_pause_update[] = {1, 1};
> + struct aspeed_jtag *aspeed_jtag = jtag_priv(jtag);
> + unsigned long *data = (unsigned long *)xfer_data;
> + unsigned long remain_xfer = xfer->length;
> + unsigned long offset;
> + char dbg_str[256];
> + int pos = 0;
> + int i;
> +
> + for (offset = 0, i = 0; offset < xfer->length;
> + offset += ASPEED_JTAG_DATA_CHUNK_SIZE, i++) {
It looks like offset is unused.
> + pos += snprintf(&dbg_str[pos], sizeof(dbg_str) - pos,
> + "0x%08lx ", data[i]);
> + }
> +
> + dev_dbg(aspeed_jtag->dev, "aspeed_jtag %s %s xfer, mode:%s, END:%d, len:%lu, TDI[%s]\n",
> + xfer->type == JTAG_SIR_XFER ? "SIR" : "SDR",
> + xfer->direction == JTAG_READ_XFER ? "READ" : "WRITE",
> + aspeed_jtag->mode & JTAG_XFER_HW_MODE ? "HW" : "SW",
> + xfer->endstate, remain_xfer, dbg_str);
> +
> + if (!(aspeed_jtag->mode & JTAG_XFER_HW_MODE)) {
> + /* SW mode */
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_SW_MODE_EN |
> + ASPEED_JTAG_SW_MODE_TDIO, ASPEED_JTAG_SW);
> +
> + if (aspeed_jtag->status != JTAG_STATE_IDLE) {
> + /*IR/DR Pause->Exit2 IR / DR->Update IR /DR */
> + aspeed_jtag_sm_cycle(aspeed_jtag, sm_pause_update,
> + sizeof(sm_pause_update));
> + }
> +
> + if (xfer->type == JTAG_SIR_XFER)
> + /* ->IRSCan->CapIR->ShiftIR */
> + aspeed_jtag_sm_cycle(aspeed_jtag, sm_update_shiftir,
> + sizeof(sm_update_shiftir));
> + else
> + /* ->DRScan->DRCap->DRShift */
> + aspeed_jtag_sm_cycle(aspeed_jtag, sm_update_shiftdr,
> + sizeof(sm_update_shiftdr));
> +
> + aspeed_jtag_xfer_sw(aspeed_jtag, xfer, data);
> +
> + /* DIPause/DRPause */
> + aspeed_jtag_tck_cycle(aspeed_jtag, 0, 0);
> +
> + if (xfer->endstate == JTAG_STATE_IDLE) {
> + /* ->DRExit2->DRUpdate->IDLE */
> + aspeed_jtag_sm_cycle(aspeed_jtag, sm_pause_idle,
> + sizeof(sm_pause_idle));
> + }
> + } else {
> + /* hw mode */
> + aspeed_jtag_write(aspeed_jtag, 0, ASPEED_JTAG_SW);
> + aspeed_jtag_xfer_hw(aspeed_jtag, xfer, data);
> + }
> +
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_SW_MODE_EN |
> + ASPEED_JTAG_SW_MODE_TDIO, ASPEED_JTAG_SW);
> + aspeed_jtag->status = xfer->endstate;
> + return 0;
> +}
>
> +
> +static irqreturn_t aspeed_jtag_interrupt(s32 this_irq, void *dev_id)
> +{
> + struct aspeed_jtag *aspeed_jtag = dev_id;
> + irqreturn_t ret;
> + u32 status;
> +
> + status = aspeed_jtag_read(aspeed_jtag, ASPEED_JTAG_ISR);
> + dev_dbg(aspeed_jtag->dev, "status %x\n", status);
> +
> + if (status & ASPEED_JTAG_ISR_INT_MASK) {
> + aspeed_jtag_write(aspeed_jtag,
> + (status & ASPEED_JTAG_ISR_INT_MASK)
> + | (status & ASPEED_JTAG_ISR_INT_EN_MASK),
> + ASPEED_JTAG_ISR);
> + aspeed_jtag->flag |= status & ASPEED_JTAG_ISR_INT_MASK;
> + }
> +
> + if (aspeed_jtag->flag) {
> + wake_up_interruptible(&aspeed_jtag->jtag_wq);
> + ret = IRQ_HANDLED;
> + } else {
> + dev_err(aspeed_jtag->dev, "aspeed_jtag irq status:%x\n",
using dev_err will give you sensible prefixes for any messages that
print out. You could remove "aspeed_jtag" from this any any other
prints you have.
> + status);
> + ret = IRQ_NONE;
> + }
> + return ret;
> +}
> +
> +int aspeed_jtag_init(struct platform_device *pdev,
> + struct aspeed_jtag *aspeed_jtag)
> +{
> + struct resource *res;
> + int err;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + aspeed_jtag->reg_base = devm_ioremap_resource(aspeed_jtag->dev, res);
> + if (IS_ERR(aspeed_jtag->reg_base))
> + return -ENOMEM;
> +
> + aspeed_jtag->pclk = devm_clk_get(aspeed_jtag->dev, NULL);
> + if (IS_ERR(aspeed_jtag->pclk)) {
> + dev_err(aspeed_jtag->dev, "devm_clk_get failed\n");
> + return PTR_ERR(aspeed_jtag->pclk);
> + }
> +
> + clk_prepare_enable(aspeed_jtag->pclk);
Can you move this below the platform_get_irq? that way you can return
an error if the getting the IRQ fails, without having to clean up the
clock.
> +
> + aspeed_jtag->irq = platform_get_irq(pdev, 0);
> + if (aspeed_jtag->irq < 0) {
> + dev_err(aspeed_jtag->dev, "no irq specified\n");
> + err = -ENOENT;
> + goto clk_unprep;
> + }
> +
> + /* Enable clock */
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_CTL_ENG_EN |
> + ASPEED_JTAG_CTL_ENG_OUT_EN, ASPEED_JTAG_CTRL);
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_SW_MODE_EN |
> + ASPEED_JTAG_SW_MODE_TDIO, ASPEED_JTAG_SW);
> +
> + err = devm_request_irq(aspeed_jtag->dev, aspeed_jtag->irq,
> + aspeed_jtag_interrupt, 0,
> + "aspeed-jtag", aspeed_jtag);
> + if (err) {
> + dev_err(aspeed_jtag->dev, "aspeed_jtag unable to get IRQ");
> + goto clk_unprep;
> + }
> + dev_dbg(&pdev->dev, "aspeed_jtag:IRQ %d.\n", aspeed_jtag->irq);
Again, remove the aspeed_jtag prefix.
> +
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_ISR_INST_PAUSE |
> + ASPEED_JTAG_ISR_INST_COMPLETE |
> + ASPEED_JTAG_ISR_DATA_PAUSE |
> + ASPEED_JTAG_ISR_DATA_COMPLETE |
> + ASPEED_JTAG_ISR_INST_PAUSE_EN |
> + ASPEED_JTAG_ISR_INST_COMPLETE_EN |
> + ASPEED_JTAG_ISR_DATA_PAUSE_EN |
> + ASPEED_JTAG_ISR_DATA_COMPLETE_EN,
> + ASPEED_JTAG_ISR);
> +
> + aspeed_jtag->flag = 0;
> + aspeed_jtag->mode = 0;
> + init_waitqueue_head(&aspeed_jtag->jtag_wq);
> + return 0;
> +
> +clk_unprep:
> + clk_disable_unprepare(aspeed_jtag->pclk);
> + return err;
> +}
> +
> +int aspeed_jtag_deinit(struct platform_device *pdev,
> + struct aspeed_jtag *aspeed_jtag)
> +{
> + aspeed_jtag_write(aspeed_jtag, 0, ASPEED_JTAG_ISR);
> + /* Disable clock */
> + aspeed_jtag_write(aspeed_jtag, 0, ASPEED_JTAG_CTRL);
> + clk_disable_unprepare(aspeed_jtag->pclk);
> + return 0;
> +}
> +
> +static const struct jtag_ops aspeed_jtag_ops = {
> + .freq_get = aspeed_jtag_freq_get,
> + .freq_set = aspeed_jtag_freq_set,
> + .status_get = aspeed_jtag_status_get,
> + .idle = aspeed_jtag_idle,
> + .xfer = aspeed_jtag_xfer,
> + .mode_set = aspeed_jtag_mode_set
> +};
> +
> +static int aspeed_jtag_probe(struct platform_device *pdev)
> +{
> + struct aspeed_jtag *aspeed_jtag;
> + struct device *dev;
> + struct jtag *jtag;
> + int err;
> +
> + dev = &pdev->dev;
> + if (!of_device_is_compatible(pdev->dev.of_node,
> + "aspeed,ast2500-jtag") &&
> + !of_device_is_compatible(pdev->dev.of_node,
> + "aspeed,ast2400-jtag"))
> + return -ENODEV;
Given the Aspeed device only ever probes with device tree, can you
drop these redundant checks?
> +
> + jtag = jtag_alloc(sizeof(*aspeed_jtag), &aspeed_jtag_ops);
> + if (!jtag)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, jtag);
> + aspeed_jtag = jtag_priv(jtag);
> + aspeed_jtag->dev = &pdev->dev;
> +
> + /* Initialize device*/
> + err = aspeed_jtag_init(pdev, aspeed_jtag);
> + if (err)
> + goto err_jtag_init;
> +
> + /* Initialize JTAG core structure*/
> + err = jtag_register(jtag);
> + if (err)
> + goto err_jtag_register;
> +
> + return 0;
> +
> +err_jtag_register:
> + aspeed_jtag_deinit(pdev, aspeed_jtag);
> +err_jtag_init:
> + jtag_free(jtag);
> + return err;
> +}
> +
> +static int aspeed_jtag_remove(struct platform_device *pdev)
> +{
> + struct jtag *jtag;
> +
> + jtag = platform_get_drvdata(pdev);
> + aspeed_jtag_deinit(pdev, jtag_priv(jtag));
> + jtag_unregister(jtag);
> + jtag_free(jtag);
> + return 0;
> +}
> +
> +static const struct of_device_id aspeed_jtag_of_match[] = {
> + { .compatible = "aspeed,ast2400-jtag", },
> + { .compatible = "aspeed,ast2500-jtag", },
> + {}
> +};
> +
> +static struct platform_driver aspeed_jtag_driver = {
> + .probe = aspeed_jtag_probe,
> + .remove = aspeed_jtag_remove,
> + .driver = {
> + .name = ASPEED_JTAG_NAME,
> + .of_match_table = aspeed_jtag_of_match,
> + },
> +};
> +module_platform_driver(aspeed_jtag_driver);
> +
> +MODULE_AUTHOR("Oleksandr Shamray <oleksandrs@mellanox.com>");
> +MODULE_DESCRIPTION("ASPEED JTAG driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.1
>
^ permalink raw reply
* [PATCH] perf probe arm64: Fix symbol fixup issues due to ELF type
From: Kim Phillips @ 2017-12-14 23:52 UTC (permalink / raw)
To: linux-arm-kernel
On an arm64 machine running a CONFIG_RANDOMIZE_BASE=y kernel, perf
kernel symbol resolution fails. Debugging saw symsrc_init calling the
default elf__needs_adjust_symbols() where checks for an ET_DYN (3)
ehdr.e_type failed when they should have succeeded.
Fix by adopting powerpc version of the weak elf__needs_adjust_symbols()
function, as done in commit d2332098331f ("perf probe ppc: Fix symbol
fixup issues due to ELF type").
Prior to this patch, perf test 1 would fail:
$ sudo oldperf test -v 1 |& head
1: vmlinux symtab matches kallsyms :
test child forked, pid 33374
Looking at the vmlinux_path (8 entries long)
Using /usr/lib/debug/boot/vmlinux for symbols
ERR : 0xfffe0000100f1000: do_undefinstr not on kallsyms
ERR : 0xfffe0000100f1320: do_sysinstr not on kallsyms
ERR : 0xfffe0000100f13b0: do_debug_exception not on kallsyms
ERR : 0xfffe0000100f1498: do_mem_abort not on kallsyms
ERR : 0xfffe0000100f1580: do_sp_pc_abort not on kallsyms
...
After applying this patch, perf test 1 now succeeds:
$ sudo ./newperf test -v 1 |& head
1: vmlinux symtab matches kallsyms :
test child forked, pid 33378
Looking at the vmlinux_path (8 entries long)
Using /usr/lib/debug/boot/vmlinux for symbols
WARN: 0xffff000008081000: diff name v: do_undefinstr k:
__exception_text_start
WARN: 0xffff0000080819e8: diff name v: __irqentry_text_end k:
__softirqentry_text_start
WARN: 0xffff000008081d08: diff name v: __entry_text_start k:
__softirqentry_text_end
WARN: 0xffff00000809db5c: diff name v: flush_icache_range k:
__flush_cache_user_range
WARN: 0xffff000008101908: diff name v: sys_ni_syscall k: sys_vm86old
...
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
---
tools/perf/arch/arm64/util/Build | 1 +
tools/perf/arch/arm64/util/sym-handling.c | 22 ++++++++++++++++++++++
2 files changed, 23 insertions(+)
create mode 100644 tools/perf/arch/arm64/util/sym-handling.c
diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
index b1ab72d2a42e..e04f6cdd6f32 100644
--- a/tools/perf/arch/arm64/util/Build
+++ b/tools/perf/arch/arm64/util/Build
@@ -1,4 +1,5 @@
libperf-y += header.o
+libperf-y += sym-handling.o
libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
diff --git a/tools/perf/arch/arm64/util/sym-handling.c b/tools/perf/arch/arm64/util/sym-handling.c
new file mode 100644
index 000000000000..0051b1ee8450
--- /dev/null
+++ b/tools/perf/arch/arm64/util/sym-handling.c
@@ -0,0 +1,22 @@
+/*
+ * 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.
+ *
+ * Copyright (C) 2015 Naveen N. Rao, IBM Corporation
+ */
+
+#include "debug.h"
+#include "symbol.h"
+#include "map.h"
+#include "probe-event.h"
+#include "probe-file.h"
+
+#ifdef HAVE_LIBELF_SUPPORT
+bool elf__needs_adjust_symbols(GElf_Ehdr ehdr)
+{
+ return ehdr.e_type == ET_EXEC ||
+ ehdr.e_type == ET_REL ||
+ ehdr.e_type == ET_DYN;
+}
+#endif
--
2.15.1
^ permalink raw reply related
* [RFC][PATCH] arm64: Switch to %px for printing some addresses at bootup
From: Laura Abbott @ 2017-12-14 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jK1H1+VSENq9uVGJsqOkB42WvZuRviyPpSmgywUmXte8A@mail.gmail.com>
On 12/14/2017 02:51 PM, Kees Cook wrote:
> On Thu, Dec 14, 2017 at 2:39 PM, Laura Abbott <labbott@redhat.com> wrote:
>> With the move to stricter %p printing, several of the addresses
>> are no longer printed out. Switch to %px so they always get printed.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> I'll admit to finding the new %p restrictions particularly irritating
>> here because I like seeing the print out of the virtual addresses for
>> debugging and checking. It might also be worth discussing whether we
>> should be printing anything out?
>
> If they're always printed at boot, I think they should likely be removed...
>
> -Kees
>
Yeah, I suspected as much. I'll submit a patch to just remove it
unless someone has a counter proposal.
Thanks,
Laura
>> ---
>> arch/arm64/mm/init.c | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 5960bef0170d..9be53e050f50 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -613,15 +613,15 @@ void __init mem_init(void)
>> MLM(MODULES_VADDR, MODULES_END));
>> pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
>> MLG(VMALLOC_START, VMALLOC_END));
>> - pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .text : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(_text, _etext));
>> - pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .rodata : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(__start_rodata, __init_begin));
>> - pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .init : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(__init_begin, __init_end));
>> - pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .data : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(_sdata, _edata));
>> - pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .bss : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(__bss_start, __bss_stop));
>> pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
>> MLK(FIXADDR_START, FIXADDR_TOP));
>> --
>> 2.14.3
>>
>
>
>
^ 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