* Re: [RESEND PATCH v2 1/3] dt-bindings: phy: Drop reset-gpios from marvell,mmp3-hsic-phy
From: Kishon Vijay Abraham I @ 2020-05-13 2:33 UTC (permalink / raw)
To: Lubomir Rintel, Rob Herring; +Cc: linux-kernel, devicetree
In-Reply-To: <20200509081754.474787-2-lkundrak@v3.sk>
+Rob
On 5/9/2020 1:47 PM, Lubomir Rintel wrote:
> This has been added in error -- the PHY block doesn't have a reset pin.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> .../devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
> index 00609ace677c..30e290c57930 100644
> --- a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
> @@ -18,27 +18,20 @@ properties:
> maxItems: 1
> description: base address of the device
>
> - reset-gpios:
> - maxItems: 1
> - description: GPIO connected to reset
> -
> "#phy-cells":
> const: 0
>
> required:
> - compatible
> - reg
> - - reset-gpios
> - "#phy-cells"
>
> additionalProperties: false
>
> examples:
> - |
> - #include <dt-bindings/gpio/gpio.h>
> hsic-phy@f0001800 {
> compatible = "marvell,mmp3-hsic-phy";
> reg = <0xf0001800 0x40>;
> - reset-gpios = <&gpio 63 GPIO_ACTIVE_HIGH>;
> #phy-cells = <0>;
> };
>
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: display: sun8i-mixer: Allow for an iommu property
From: Rob Herring @ 2020-05-13 2:22 UTC (permalink / raw)
To: Maxime Ripard
Cc: Joerg Roedel, Rob Herring, devicetree, Chen-Yu Tsai, Frank Rowand,
Maxime Ripard, iommu, linux-arm-kernel, Mark Rutland
In-Reply-To: <ef88e9d96eafe3f921cfbe087c5f0a25a5dd41ac.1588673353.git-series.maxime@cerno.tech>
On Tue, 5 May 2020 12:09:31 +0200, Maxime Ripard wrote:
> The H6 mixer is attached to an IOMMU, so let's allow that property to be
> set in the bindings.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: i2c-stm32: add SMBus Alert bindings
From: Rob Herring @ 2020-05-13 2:19 UTC (permalink / raw)
To: Alain Volmat
Cc: wsa, mark.rutland, pierre-yves.mordret, mcoquelin.stm32,
alexandre.torgue, linux-i2c, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel, fabrice.gasnier
In-Reply-To: <1588657871-14747-4-git-send-email-alain.volmat@st.com>
On Tue, May 05, 2020 at 07:51:10AM +0200, Alain Volmat wrote:
> Add a new binding of the i2c-stm32f7 driver to enable the handling
> of the SMBUS-Alert
>
> Signed-off-by: Alain Volmat <alain.volmat@st.com>
> ---
> Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
> index b50a2f420b36..04c0882c3661 100644
> --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
> @@ -36,6 +36,10 @@ allOf:
> minItems: 3
> maxItems: 3
>
> + st,smbus-alert:
> + description: Enable the SMBus Alert feature
> + $ref: /schemas/types.yaml#/definitions/flag
> +
We already have smbus_alert interrupt. Can't you just check for this in
the slave nodes and enable if found?
> - if:
> properties:
> compatible:
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: power: supply: Document maxim,rcomp-value for max17040
From: Rob Herring @ 2020-05-13 2:16 UTC (permalink / raw)
To: Jonathan Bakker; +Cc: linux-kernel, devicetree, sre, linux-pm, robh+dt
In-Reply-To: <BN6PR04MB0660F4D09451AE8F1DB284D3A3A60@BN6PR04MB0660.namprd04.prod.outlook.com>
On Mon, 4 May 2020 15:12:59 -0700, Jonathan Bakker wrote:
> The rcomp value is a device-specific value for configuration based
> on specific chemistries. There is no public documentation on how
> to tune it.
>
> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
> ---
> .../devicetree/bindings/power/supply/max17040_battery.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 RESEND 2/2] Input: remove msm-vibrator driver
From: Brian Masney @ 2020-05-13 1:31 UTC (permalink / raw)
To: dmitry.torokhov
Cc: robh+dt, linux-input, linux-kernel, devicetree, linux-arm-msm,
sboyd
In-Reply-To: <20200513013140.69935-1-masneyb@onstation.org>
The address referenced by this driver is within the Qualcomm Clock
namespace so let's drop the msm-vibrator bindings so that a more generic
solution can be used instead. No one is currently using driver so this
won't affect any users.
Signed-off-by: Brian Masney <masneyb@onstation.org>
---
drivers/input/misc/Kconfig | 10 --
drivers/input/misc/Makefile | 1 -
drivers/input/misc/msm-vibrator.c | 281 ------------------------------
3 files changed, 292 deletions(-)
delete mode 100644 drivers/input/misc/msm-vibrator.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7e2e658d551c..b56da7a5efb9 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -117,16 +117,6 @@ config INPUT_E3X0_BUTTON
To compile this driver as a module, choose M here: the
module will be called e3x0_button.
-config INPUT_MSM_VIBRATOR
- tristate "Qualcomm MSM vibrator driver"
- select INPUT_FF_MEMLESS
- help
- Support for the vibrator that is found on various Qualcomm MSM
- SOCs.
-
- To compile this driver as a module, choose M here: the module
- will be called msm_vibrator.
-
config INPUT_PCSPKR
tristate "PC Speaker support"
depends on PCSPKR_PLATFORM
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 8fd187f314bd..e6768b61a955 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -50,7 +50,6 @@ obj-$(CONFIG_INPUT_MAX8925_ONKEY) += max8925_onkey.o
obj-$(CONFIG_INPUT_MAX8997_HAPTIC) += max8997_haptic.o
obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
obj-$(CONFIG_INPUT_MMA8450) += mma8450.o
-obj-$(CONFIG_INPUT_MSM_VIBRATOR) += msm-vibrator.o
obj-$(CONFIG_INPUT_PALMAS_PWRBUTTON) += palmas-pwrbutton.o
obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o
obj-$(CONFIG_INPUT_PCF50633_PMU) += pcf50633-input.o
diff --git a/drivers/input/misc/msm-vibrator.c b/drivers/input/misc/msm-vibrator.c
deleted file mode 100644
index b60f1aaee705..000000000000
--- a/drivers/input/misc/msm-vibrator.c
+++ /dev/null
@@ -1,281 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Qualcomm MSM vibrator driver
- *
- * Copyright (c) 2018 Brian Masney <masneyb@onstation.org>
- *
- * Based on qcom,pwm-vibrator.c from:
- * Copyright (c) 2018 Jonathan Marek <jonathan@marek.ca>
- *
- * Based on msm_pwm_vibrator.c from downstream Android sources:
- * Copyright (C) 2009-2014 LGE, Inc.
- */
-
-#include <linux/clk.h>
-#include <linux/err.h>
-#include <linux/gpio/consumer.h>
-#include <linux/input.h>
-#include <linux/io.h>
-#include <linux/module.h>
-#include <linux/of.h>
-#include <linux/platform_device.h>
-#include <linux/regulator/consumer.h>
-
-#define REG_CMD_RCGR 0x00
-#define REG_CFG_RCGR 0x04
-#define REG_M 0x08
-#define REG_N 0x0C
-#define REG_D 0x10
-#define REG_CBCR 0x24
-#define MMSS_CC_M_DEFAULT 1
-
-struct msm_vibrator {
- struct input_dev *input;
- struct mutex mutex;
- struct work_struct worker;
- void __iomem *base;
- struct regulator *vcc;
- struct clk *clk;
- struct gpio_desc *enable_gpio;
- u16 magnitude;
- bool enabled;
-};
-
-static void msm_vibrator_write(struct msm_vibrator *vibrator, int offset,
- u32 value)
-{
- writel(value, vibrator->base + offset);
-}
-
-static int msm_vibrator_start(struct msm_vibrator *vibrator)
-{
- int d_reg_val, ret = 0;
-
- mutex_lock(&vibrator->mutex);
-
- if (!vibrator->enabled) {
- ret = clk_set_rate(vibrator->clk, 24000);
- if (ret) {
- dev_err(&vibrator->input->dev,
- "Failed to set clock rate: %d\n", ret);
- goto unlock;
- }
-
- ret = clk_prepare_enable(vibrator->clk);
- if (ret) {
- dev_err(&vibrator->input->dev,
- "Failed to enable clock: %d\n", ret);
- goto unlock;
- }
-
- ret = regulator_enable(vibrator->vcc);
- if (ret) {
- dev_err(&vibrator->input->dev,
- "Failed to enable regulator: %d\n", ret);
- clk_disable(vibrator->clk);
- goto unlock;
- }
-
- gpiod_set_value_cansleep(vibrator->enable_gpio, 1);
-
- vibrator->enabled = true;
- }
-
- d_reg_val = 127 - ((126 * vibrator->magnitude) / 0xffff);
- msm_vibrator_write(vibrator, REG_CFG_RCGR,
- (2 << 12) | /* dual edge mode */
- (0 << 8) | /* cxo */
- (7 << 0));
- msm_vibrator_write(vibrator, REG_M, 1);
- msm_vibrator_write(vibrator, REG_N, 128);
- msm_vibrator_write(vibrator, REG_D, d_reg_val);
- msm_vibrator_write(vibrator, REG_CMD_RCGR, 1);
- msm_vibrator_write(vibrator, REG_CBCR, 1);
-
-unlock:
- mutex_unlock(&vibrator->mutex);
-
- return ret;
-}
-
-static void msm_vibrator_stop(struct msm_vibrator *vibrator)
-{
- mutex_lock(&vibrator->mutex);
-
- if (vibrator->enabled) {
- gpiod_set_value_cansleep(vibrator->enable_gpio, 0);
- regulator_disable(vibrator->vcc);
- clk_disable(vibrator->clk);
- vibrator->enabled = false;
- }
-
- mutex_unlock(&vibrator->mutex);
-}
-
-static void msm_vibrator_worker(struct work_struct *work)
-{
- struct msm_vibrator *vibrator = container_of(work,
- struct msm_vibrator,
- worker);
-
- if (vibrator->magnitude)
- msm_vibrator_start(vibrator);
- else
- msm_vibrator_stop(vibrator);
-}
-
-static int msm_vibrator_play_effect(struct input_dev *dev, void *data,
- struct ff_effect *effect)
-{
- struct msm_vibrator *vibrator = input_get_drvdata(dev);
-
- mutex_lock(&vibrator->mutex);
-
- if (effect->u.rumble.strong_magnitude > 0)
- vibrator->magnitude = effect->u.rumble.strong_magnitude;
- else
- vibrator->magnitude = effect->u.rumble.weak_magnitude;
-
- mutex_unlock(&vibrator->mutex);
-
- schedule_work(&vibrator->worker);
-
- return 0;
-}
-
-static void msm_vibrator_close(struct input_dev *input)
-{
- struct msm_vibrator *vibrator = input_get_drvdata(input);
-
- cancel_work_sync(&vibrator->worker);
- msm_vibrator_stop(vibrator);
-}
-
-static int msm_vibrator_probe(struct platform_device *pdev)
-{
- struct msm_vibrator *vibrator;
- struct resource *res;
- int ret;
-
- vibrator = devm_kzalloc(&pdev->dev, sizeof(*vibrator), GFP_KERNEL);
- if (!vibrator)
- return -ENOMEM;
-
- vibrator->input = devm_input_allocate_device(&pdev->dev);
- if (!vibrator->input)
- return -ENOMEM;
-
- vibrator->vcc = devm_regulator_get(&pdev->dev, "vcc");
- if (IS_ERR(vibrator->vcc)) {
- if (PTR_ERR(vibrator->vcc) != -EPROBE_DEFER)
- dev_err(&pdev->dev, "Failed to get regulator: %ld\n",
- PTR_ERR(vibrator->vcc));
- return PTR_ERR(vibrator->vcc);
- }
-
- vibrator->enable_gpio = devm_gpiod_get(&pdev->dev, "enable",
- GPIOD_OUT_LOW);
- if (IS_ERR(vibrator->enable_gpio)) {
- if (PTR_ERR(vibrator->enable_gpio) != -EPROBE_DEFER)
- dev_err(&pdev->dev, "Failed to get enable gpio: %ld\n",
- PTR_ERR(vibrator->enable_gpio));
- return PTR_ERR(vibrator->enable_gpio);
- }
-
- vibrator->clk = devm_clk_get(&pdev->dev, "pwm");
- if (IS_ERR(vibrator->clk)) {
- if (PTR_ERR(vibrator->clk) != -EPROBE_DEFER)
- dev_err(&pdev->dev, "Failed to lookup pwm clock: %ld\n",
- PTR_ERR(vibrator->clk));
- return PTR_ERR(vibrator->clk);
- }
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "Failed to get platform resource\n");
- return -ENODEV;
- }
-
- vibrator->base = devm_ioremap(&pdev->dev, res->start,
- resource_size(res));
- if (!vibrator->base) {
- dev_err(&pdev->dev, "Failed to iomap resource.\n");
- return -ENOMEM;
- }
-
- vibrator->enabled = false;
- mutex_init(&vibrator->mutex);
- INIT_WORK(&vibrator->worker, msm_vibrator_worker);
-
- vibrator->input->name = "msm-vibrator";
- vibrator->input->id.bustype = BUS_HOST;
- vibrator->input->close = msm_vibrator_close;
-
- input_set_drvdata(vibrator->input, vibrator);
- input_set_capability(vibrator->input, EV_FF, FF_RUMBLE);
-
- ret = input_ff_create_memless(vibrator->input, NULL,
- msm_vibrator_play_effect);
- if (ret) {
- dev_err(&pdev->dev, "Failed to create ff memless: %d", ret);
- return ret;
- }
-
- ret = input_register_device(vibrator->input);
- if (ret) {
- dev_err(&pdev->dev, "Failed to register input device: %d", ret);
- return ret;
- }
-
- platform_set_drvdata(pdev, vibrator);
-
- return 0;
-}
-
-static int __maybe_unused msm_vibrator_suspend(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct msm_vibrator *vibrator = platform_get_drvdata(pdev);
-
- cancel_work_sync(&vibrator->worker);
-
- if (vibrator->enabled)
- msm_vibrator_stop(vibrator);
-
- return 0;
-}
-
-static int __maybe_unused msm_vibrator_resume(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct msm_vibrator *vibrator = platform_get_drvdata(pdev);
-
- if (vibrator->enabled)
- msm_vibrator_start(vibrator);
-
- return 0;
-}
-
-static SIMPLE_DEV_PM_OPS(msm_vibrator_pm_ops, msm_vibrator_suspend,
- msm_vibrator_resume);
-
-static const struct of_device_id msm_vibrator_of_match[] = {
- { .compatible = "qcom,msm8226-vibrator" },
- { .compatible = "qcom,msm8974-vibrator" },
- {},
-};
-MODULE_DEVICE_TABLE(of, msm_vibrator_of_match);
-
-static struct platform_driver msm_vibrator_driver = {
- .probe = msm_vibrator_probe,
- .driver = {
- .name = "msm-vibrator",
- .pm = &msm_vibrator_pm_ops,
- .of_match_table = of_match_ptr(msm_vibrator_of_match),
- },
-};
-module_platform_driver(msm_vibrator_driver);
-
-MODULE_AUTHOR("Brian Masney <masneyb@onstation.org>");
-MODULE_DESCRIPTION("Qualcomm MSM vibrator driver");
-MODULE_LICENSE("GPL");
--
2.24.1
^ permalink raw reply related
* [PATCH v2 RESEND 0/2] Input: remove msm-vibrator driver and bindings
From: Brian Masney @ 2020-05-13 1:31 UTC (permalink / raw)
To: dmitry.torokhov
Cc: robh+dt, linux-input, linux-kernel, devicetree, linux-arm-msm,
sboyd
Here's a small patch series that removes the msm-vibrator driver and
bindings. These two patches are broken out from this patch series from
December:
https://lore.kernel.org/lkml/20191205002503.13088-5-masneyb@onstation.org/
And a resend of what I sent out in February:
https://lore.kernel.org/lkml/20200211121318.144067-1-masneyb@onstation.org/
In a nutshell, the address referenced by this driver is within the
Qualcomm Clock namespace and needs to be managed by the clk subsystem.
This driver needs to go away to clean up the upstream kernel.
I'm waiting for someone from Qualcomm to either post a patch to support
setting the clock duty cycle or someone to post information about the
m,n,d registers for the clocks. Once that's done, no other changes
will be needed in the input subsystem.
Brian Masney (2):
dt-bindings: Input: remove msm-vibrator
Input: remove msm-vibrator driver
.../bindings/input/msm-vibrator.txt | 36 ---
drivers/input/misc/Kconfig | 10 -
drivers/input/misc/Makefile | 1 -
drivers/input/misc/msm-vibrator.c | 281 ------------------
4 files changed, 328 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/msm-vibrator.txt
delete mode 100644 drivers/input/misc/msm-vibrator.c
--
2.24.1
^ permalink raw reply
* [PATCH v2 RESEND 1/2] dt-bindings: Input: remove msm-vibrator
From: Brian Masney @ 2020-05-13 1:31 UTC (permalink / raw)
To: dmitry.torokhov
Cc: robh+dt, linux-input, linux-kernel, devicetree, linux-arm-msm,
sboyd, Rob Herring
In-Reply-To: <20200513013140.69935-1-masneyb@onstation.org>
The address referenced in this binding is within the Qualcomm Clock
namespace so let's drop the msm-vibrator bindings so that a more
generic solution can be used instead. No one is currently using these
bindings so this won't affect any users.
Signed-off-by: Brian Masney <masneyb@onstation.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/input/msm-vibrator.txt | 36 -------------------
1 file changed, 36 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/msm-vibrator.txt
diff --git a/Documentation/devicetree/bindings/input/msm-vibrator.txt b/Documentation/devicetree/bindings/input/msm-vibrator.txt
deleted file mode 100644
index 8dcf014ef2e5..000000000000
--- a/Documentation/devicetree/bindings/input/msm-vibrator.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* Device tree bindings for the Qualcomm MSM vibrator
-
-Required properties:
-
- - compatible: Should be one of
- "qcom,msm8226-vibrator"
- "qcom,msm8974-vibrator"
- - reg: the base address and length of the IO memory for the registers.
- - pinctrl-names: set to default.
- - pinctrl-0: phandles pointing to pin configuration nodes. See
- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
- - clock-names: set to pwm
- - clocks: phandle of the clock. See
- Documentation/devicetree/bindings/clock/clock-bindings.txt
- - enable-gpios: GPIO that enables the vibrator.
-
-Optional properties:
-
- - vcc-supply: phandle to the regulator that provides power to the sensor.
-
-Example from a LG Nexus 5 (hammerhead) phone:
-
-vibrator@fd8c3450 {
- reg = <0xfd8c3450 0x400>;
- compatible = "qcom,msm8974-vibrator";
-
- vcc-supply = <&pm8941_l19>;
-
- clocks = <&mmcc CAMSS_GP1_CLK>;
- clock-names = "pwm";
-
- enable-gpios = <&msmgpio 60 GPIO_ACTIVE_HIGH>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&vibrator_pin>;
-};
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v9 2/5] PCI: Add Loongson PCI Controller support
From: Jiaxun Yang @ 2020-05-13 1:20 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci, Rob Herring, Bjorn Helgaas, Rob Herring,
Thomas Bogendoerfer, Huacai Chen, Lorenzo Pieralisi, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200512180602.GA273658@bjorn-Precision-5520>
于 2020年5月13日 GMT+08:00 上午2:06:02, Bjorn Helgaas <helgaas@kernel.org> 写到:
>On Tue, May 12, 2020 at 03:43:56PM +0800, Jiaxun Yang wrote:
>> This controller can be found on Loongson-2K SoC, Loongson-3
>> systems with RS780E/LS7A PCH.
>>
>> The RS780E part of code was previously located at
>> arch/mips/pci/ops-loongson3.c and now it can use generic PCI
>> driver implementation.
>>
>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>
>> +static void system_bus_quirk(struct pci_dev *pdev)
>> +{
>> + u16 tmp;
>> +
>> + /*
>> + * These devices are not sharing resouces with rest of devices
>> + * on host bus and firmware will ensure their BARs are placed
>> + * in safe ranges. Also there might be some config registers
>> + * in their config space so kernel shouldn't ignore them.
>
>"Firmware ensuring BARs are placed in 'safe' ranges" is not a
>sufficient answer. As I said before, Linux needs to know both the
>ADDRESS and the SIZE of whatever non-standard BARs these are.
>Otherwise, we're liable to assign that space to a different device.
The address assigned to these devices will never be a part of resources
belongs to the host bridge. That's enforced by hardware and firmware,
so address conflict would never happen.
I'm doing like this to ensure kernel will discover this device but do nothing
about assignment of resources to it.
>
>If you have to hard-code the size, so be it. That would mean the
>hardware is completely broken, but at least we could make Linux deal
>with it. If the hardware consumes address space we don't know about,
>we can't deal with that.
>
>> + */
>> + pdev->mmio_always_on = 1;
>> + pdev->non_compliant_bars = 1;
>> +}
>
>> +void __iomem *pci_loongson_map_bus(struct pci_bus *bus, unsigned int devfn,
>> + int where)
>> +{
>> + unsigned char busnum = bus->number;
>> + struct pci_host_bridge *bridge = pci_find_host_bridge(bus);
>> + struct loongson_pci *priv = pci_host_bridge_priv(bridge);
>> +
>> + /*
>> + * Do not read more than one device on the bus other than
>> + * the host bus 0.
>> + */
>
>If the hardware is restricted such that the root bus number must be
>zero, pleae say that explicitly here. Otherwise, it just looks like
>a bug.
>
>> + if (priv->flags & FLAG_DEV_FIX && busnum != 0 &&
>> + PCI_SLOT(devfn) > 0)
>> + return NULL;
>> +
>> + /* CFG0 can only access standard space */
>> + if (where < PCI_CFG_SPACE_SIZE && priv->cfg0_base)
>> + return cfg0_map(priv, busnum, devfn, where);
>> +
>> + /* CFG1 can access extended space */
>> + if (where < PCI_CFG_SPACE_EXP_SIZE && priv->cfg1_base)
>> + return cfg1_map(priv, busnum, devfn, where);
>> +
>> + return NULL;
>> +}
--
Jiaxun Yang
^ permalink raw reply
* [PATCH 0/4] hwspinlock: qcom: Allow dropping the intermediate TCSR mutex syscon
From: Bjorn Andersson @ 2020-05-13 0:54 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Baolin Wang,
Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In all modern Qualcomm platforms the mutex region of the TCSR is forked
off into its own block, all with a offset of 0 and stride of 4096.
Update the binding to allow the hardware block to be described directly
on the mmio bus, in addition to allowing the existing syscon based
definition.
Bjorn Andersson (4):
dt-bindings: hwlock: qcom: Migrate binding to YAML
dt-bindings: hwlock: qcom: Allow device on mmio bus
hwspinlock: qcom: Allow mmio usage in addition to syscon
arm64: dts: qcom: sm8250: Drop tcsr_mutex syscon
.../bindings/hwlock/qcom-hwspinlock.yaml | 65 +++++++++++++++++
arch/arm64/boot/dts/qcom/sm8250.dtsi | 11 +--
drivers/hwspinlock/qcom_hwspinlock.c | 72 ++++++++++++++-----
3 files changed, 124 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
--
2.26.2
^ permalink raw reply
* [PATCH 1/4] dt-bindings: hwlock: qcom: Migrate binding to YAML
From: Bjorn Andersson @ 2020-05-13 0:54 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Baolin Wang,
Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513005441.1102586-1-bjorn.andersson@linaro.org>
Migrate the Qualcomm TCSR mutex binding to YAML to allow validation.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
.../bindings/hwlock/qcom-hwspinlock.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
new file mode 100644
index 000000000000..71e63b52edd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwlock/qcom-hwspinlock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Hardware Mutex Block
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description:
+ The hardware block provides mutexes utilized between different processors on
+ the SoC as part of the communication protocol used by these processors.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sfpb-mutex
+ - qcom,tcsr-mutex
+
+ '#hwlock-cells':
+ const: 1
+
+ syscon:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ description:
+ Should be a triple of phandle referencing the TCSR mutex syscon, offset
+ of first mutex within the syscon and stride between each mutex.
+
+required:
+ - compatible
+ - '#hwlock-cells'
+ - syscon
+
+additionalProperties: false
+
+examples:
+ - |
+ tcsr_mutex_block: syscon@fd484000 {
+ compatible = "syscon";
+ reg = <0xfd484000 0x2000>;
+ };
+
+ hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_block 0 0x80>;
+
+ #hwlock-cells = <1>;
+ };
+...
--
2.26.2
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: hwlock: qcom: Allow device on mmio bus
From: Bjorn Andersson @ 2020-05-13 0:54 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Baolin Wang,
Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513005441.1102586-1-bjorn.andersson@linaro.org>
In all modern Qualcomm platforms the mutex region of the TCSR is forked
off into its own block, all with a offset of 0 and stride of 4096.
Update the binding to allow the hardware block to be described directly
on the mmio bus, in addition to allowing the existing syscon based
definition.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
.../bindings/hwlock/qcom-hwspinlock.yaml | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
index 71e63b52edd5..88f975837588 100644
--- a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
+++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
@@ -19,6 +19,9 @@ properties:
- qcom,sfpb-mutex
- qcom,tcsr-mutex
+ reg:
+ maxItems: 1
+
'#hwlock-cells':
const: 1
@@ -31,7 +34,12 @@ properties:
required:
- compatible
- '#hwlock-cells'
- - syscon
+
+oneOf:
+ - required:
+ - reg
+ - required:
+ - syscon
additionalProperties: false
@@ -46,6 +54,12 @@ examples:
compatible = "qcom,tcsr-mutex";
syscon = <&tcsr_mutex_block 0 0x80>;
+ #hwlock-cells = <1>;
+ };
+ - |
+ tcsr_mutex: hwlock@1f40000 {
+ compatible = "qcom,tcsr-mutex";
+ reg = <0x01f40000 0x40000>;
#hwlock-cells = <1>;
};
...
--
2.26.2
^ permalink raw reply related
* [PATCH 3/4] hwspinlock: qcom: Allow mmio usage in addition to syscon
From: Bjorn Andersson @ 2020-05-13 0:54 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Baolin Wang,
Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513005441.1102586-1-bjorn.andersson@linaro.org>
In all modern Qualcomm platforms the mutex region of the TCSR is forked
off into its own block, all with a offset of 0 and stride of 4096. So
add support for directly memory mapping this register space, to avoid
the need to represent this block using a syscon.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
drivers/hwspinlock/qcom_hwspinlock.c | 72 +++++++++++++++++++++-------
1 file changed, 56 insertions(+), 16 deletions(-)
diff --git a/drivers/hwspinlock/qcom_hwspinlock.c b/drivers/hwspinlock/qcom_hwspinlock.c
index f0da544b14d2..d8d4d729816c 100644
--- a/drivers/hwspinlock/qcom_hwspinlock.c
+++ b/drivers/hwspinlock/qcom_hwspinlock.c
@@ -70,41 +70,81 @@ static const struct of_device_id qcom_hwspinlock_of_match[] = {
};
MODULE_DEVICE_TABLE(of, qcom_hwspinlock_of_match);
-static int qcom_hwspinlock_probe(struct platform_device *pdev)
+static struct regmap *qcom_hwspinlock_probe_syscon(struct platform_device *pdev,
+ u32 *base, u32 *stride)
{
- struct hwspinlock_device *bank;
struct device_node *syscon;
- struct reg_field field;
struct regmap *regmap;
- size_t array_size;
- u32 stride;
- u32 base;
int ret;
- int i;
syscon = of_parse_phandle(pdev->dev.of_node, "syscon", 0);
- if (!syscon) {
- dev_err(&pdev->dev, "no syscon property\n");
- return -ENODEV;
- }
+ if (!syscon)
+ return ERR_PTR(-ENODEV);
regmap = syscon_node_to_regmap(syscon);
of_node_put(syscon);
if (IS_ERR(regmap))
- return PTR_ERR(regmap);
+ return regmap;
- ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1, &base);
+ ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1, base);
if (ret < 0) {
dev_err(&pdev->dev, "no offset in syscon\n");
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
}
- ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 2, &stride);
+ ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 2, stride);
if (ret < 0) {
dev_err(&pdev->dev, "no stride syscon\n");
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
}
+ return regmap;
+}
+
+static const struct regmap_config tcsr_mutex_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x40000,
+ .fast_io = true,
+};
+
+static struct regmap *qcom_hwspinlock_probe_mmio(struct platform_device *pdev,
+ u32 *offset, u32 *stride)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ void __iomem *base;
+
+ /* All modern platform has offset 0 and stride of 4k */
+ *offset = 0;
+ *stride = 0x1000;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return ERR_CAST(base);
+
+ return devm_regmap_init_mmio(dev, base, &tcsr_mutex_config);
+}
+
+static int qcom_hwspinlock_probe(struct platform_device *pdev)
+{
+ struct hwspinlock_device *bank;
+ struct reg_field field;
+ struct regmap *regmap;
+ size_t array_size;
+ u32 stride;
+ u32 base;
+ int i;
+
+ regmap = qcom_hwspinlock_probe_syscon(pdev, &base, &stride);
+ if (IS_ERR(regmap) && PTR_ERR(regmap) == -ENODEV)
+ regmap = qcom_hwspinlock_probe_mmio(pdev, &base, &stride);
+
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
array_size = QCOM_MUTEX_NUM_LOCKS * sizeof(struct hwspinlock);
bank = devm_kzalloc(&pdev->dev, sizeof(*bank) + array_size, GFP_KERNEL);
if (!bank)
--
2.26.2
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: qcom: sm8250: Drop tcsr_mutex syscon
From: Bjorn Andersson @ 2020-05-13 0:54 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Baolin Wang,
Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513005441.1102586-1-bjorn.andersson@linaro.org>
Now that we don't need the intermediate syscon to represent the TCSR
mutexes, update the dts to describe the TCSR mutex directly.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index ecbcf725fba2..6e28754705b9 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -146,12 +146,6 @@ scm: scm {
};
};
- tcsr_mutex: hwlock {
- compatible = "qcom,tcsr-mutex";
- syscon = <&tcsr_mutex_regs 0 0x1000>;
- #hwlock-cells = <1>;
- };
-
memory@80000000 {
device_type = "memory";
/* We expect the bootloader to fill in the size */
@@ -569,9 +563,10 @@ rpmhpd_opp_turbo_l1: opp10 {
};
};
- tcsr_mutex_regs: syscon@1f40000 {
- compatible = "syscon";
+ tcsr_mutex: hwlock@1f40000 {
+ compatible = "qcom,tcsr-mutex";
reg = <0x0 0x01f40000 0x0 0x40000>;
+ #hwlock-cells = <1>;
};
slpi: remoteproc@5c00000 {
--
2.26.2
^ permalink raw reply related
* [PATCH V5 2/5] dt-bindings: clock: Convert i.MX6SX clock to json-schema
From: Anson Huang @ 2020-05-13 0:11 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
linux-clk, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1589328684-1397-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX6SX clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
Changes since V4:
- add descriptions for interrupts and each item of it.
---
.../devicetree/bindings/clock/imx6sx-clock.txt | 13 ----
.../devicetree/bindings/clock/imx6sx-clock.yaml | 70 ++++++++++++++++++++++
2 files changed, 70 insertions(+), 13 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx6sx-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6sx-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx6sx-clock.txt b/Documentation/devicetree/bindings/clock/imx6sx-clock.txt
deleted file mode 100644
index 22362b9..0000000
--- a/Documentation/devicetree/bindings/clock/imx6sx-clock.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-* Clock bindings for Freescale i.MX6 SoloX
-
-Required properties:
-- compatible: Should be "fsl,imx6sx-ccm"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-- clocks: list of clock specifiers, must contain an entry for each required
- entry in clock-names
-- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sx-clock.h
-for the full list of i.MX6 SoloX clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml
new file mode 100644
index 0000000..982d698
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx6sx-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX6 SoloX
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx6sx-ccm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: CCM provides 2 interrupt requests, request 1 is to generate
+ interrupt for frequency or mux change, request 2 is to generate
+ interrupt for oscillator read or PLL lock.
+ items:
+ - description: CCM interrupt request 1
+ - description: CCM interrupt request 2
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: 32k osc
+ - description: 24m osc
+ - description: ipp_di0 clock input
+ - description: ipp_di1 clock input
+ - description: anaclk1 clock input
+ - description: anaclk2 clock input
+
+ clock-names:
+ items:
+ - const: ckil
+ - const: osc
+ - const: ipp_di0
+ - const: ipp_di1
+ - const: anaclk1
+ - const: anaclk2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+examples:
+ # Clock Control Module node:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@20c4000 {
+ compatible = "fsl,imx6sx-ccm";
+ reg = <0x020c4000 0x4000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ #clock-cells = <1>;
+ clocks = <&ckil>, <&osc>, <&ipp_di0>, <&ipp_di1>, <&anaclk1>, <&anaclk2>;
+ clock-names = "ckil", "osc", "ipp_di0", "ipp_di1", "anaclk1", "anaclk2";
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH V5 1/5] dt-bindings: clock: Convert i.MX6Q clock to json-schema
From: Anson Huang @ 2020-05-13 0:11 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
linux-clk, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1589328684-1397-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX6Q clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
Changes since V4:
- add descriptions for interrupts and each item of it.
---
.../devicetree/bindings/clock/imx6q-clock.txt | 41 ------------
.../devicetree/bindings/clock/imx6q-clock.yaml | 72 ++++++++++++++++++++++
2 files changed, 72 insertions(+), 41 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx6q-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6q-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
deleted file mode 100644
index 13d36d4..0000000
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Clock bindings for Freescale i.MX6 Quad
-
-Required properties:
-- compatible: Should be "fsl,imx6q-ccm"
-- reg: Address and length of the register set
-- interrupts: Should contain CCM interrupt
-- #clock-cells: Should be <1>
-
-Optional properties:
-- fsl,pmic-stby-poweroff: Configure CCM to assert PMIC_STBY_REQ signal
- on power off.
- Use this property if the SoC should be powered off by external power
- management IC (PMIC) triggered via PMIC_STBY_REQ signal.
- Boards that are designed to initiate poweroff on PMIC_ON_REQ signal should
- be using "syscon-poweroff" driver instead.
-- clocks: list of clock specifiers, must contain an entry for each entry
- in clock-names
-- clock-names: valid names are "osc", "ckil", "ckih1", "anaclk1" and "anaclk2"
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6qdl-clock.h
-for the full list of i.MX6 Quad and DualLite clock IDs.
-
-Examples:
-
-#include <dt-bindings/clock/imx6qdl-clock.h>
-
-clks: ccm@20c4000 {
- compatible = "fsl,imx6q-ccm";
- reg = <0x020c4000 0x4000>;
- interrupts = <0 87 0x04 0 88 0x04>;
- #clock-cells = <1>;
-};
-
-uart1: serial@2020000 {
- compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
- reg = <0x02020000 0x4000>;
- interrupts = <0 26 0x04>;
- clocks = <&clks IMX6QDL_CLK_UART_IPG>, <&clks IMX6QDL_CLK_UART_SERIAL>;
- clock-names = "ipg", "per";
-};
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.yaml b/Documentation/devicetree/bindings/clock/imx6q-clock.yaml
new file mode 100644
index 0000000..429e3b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx6q-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX6 Quad
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx6q-ccm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: CCM provides 2 interrupt requests, request 1 is to generate
+ interrupt for frequency or mux change, request 2 is to generate
+ interrupt for oscillator read or PLL lock.
+ items:
+ - description: CCM interrupt request 1
+ - description: CCM interrupt request 2
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: 24m osc
+ - description: 32k osc
+ - description: ckih1 clock input
+ - description: anaclk1 clock input
+ - description: anaclk2 clock input
+
+ clock-names:
+ items:
+ - const: osc
+ - const: ckil
+ - const: ckih1
+ - const: anaclk1
+ - const: anaclk2
+
+ fsl,pmic-stby-poweroff:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Use this property if the SoC should be powered off by external power
+ management IC (PMIC) triggered via PMIC_STBY_REQ signal.
+ Boards that are designed to initiate poweroff on PMIC_ON_REQ signal should
+ be using "syscon-poweroff" driver instead.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#clock-cells'
+
+examples:
+ # Clock Control Module node:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@20c4000 {
+ compatible = "fsl,imx6q-ccm";
+ reg = <0x020c4000 0x4000>;
+ interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>,
+ <0 88 IRQ_TYPE_LEVEL_HIGH>;
+ #clock-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH V5 3/5] dt-bindings: clock: Convert i.MX6SL clock to json-schema
From: Anson Huang @ 2020-05-13 0:11 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
linux-clk, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1589328684-1397-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX6SL clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
Changes since V4:
- add descriptions for interrupts and each item of it.
---
.../devicetree/bindings/clock/imx6sl-clock.txt | 10 -----
.../devicetree/bindings/clock/imx6sl-clock.yaml | 48 ++++++++++++++++++++++
2 files changed, 48 insertions(+), 10 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.txt b/Documentation/devicetree/bindings/clock/imx6sl-clock.txt
deleted file mode 100644
index 15e40bd..0000000
--- a/Documentation/devicetree/bindings/clock/imx6sl-clock.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-* Clock bindings for Freescale i.MX6 SoloLite
-
-Required properties:
-- compatible: Should be "fsl,imx6sl-ccm"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sl-clock.h
-for the full list of i.MX6 SoloLite clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml
new file mode 100644
index 0000000..135568c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx6sl-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX6 SoloLite
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx6sl-ccm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: CCM provides 2 interrupt requests, request 1 is to generate
+ interrupt for frequency or mux change, request 2 is to generate
+ interrupt for oscillator read or PLL lock.
+ items:
+ - description: CCM interrupt request 1
+ - description: CCM interrupt request 2
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#clock-cells'
+
+examples:
+ # Clock Control Module node:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@20c4000 {
+ compatible = "fsl,imx6sl-ccm";
+ reg = <0x020c4000 0x4000>;
+ interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>,
+ <0 88 IRQ_TYPE_LEVEL_HIGH>;
+ #clock-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH V5 4/5] dt-bindings: clock: Convert i.MX6SLL clock to json-schema
From: Anson Huang @ 2020-05-13 0:11 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
linux-clk, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1589328684-1397-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX6SLL clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
Changes since V4:
- add descriptions for interrupts and each item of it.
---
.../devicetree/bindings/clock/imx6sll-clock.txt | 36 ------------
.../devicetree/bindings/clock/imx6sll-clock.yaml | 66 ++++++++++++++++++++++
2 files changed, 66 insertions(+), 36 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
deleted file mode 100644
index fee849d..0000000
--- a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* Clock bindings for Freescale i.MX6 SLL
-
-Required properties:
-- compatible: Should be "fsl,imx6sll-ccm"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-- clocks: list of clock specifiers, must contain an entry for each required
- entry in clock-names
-- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sll-clock.h
-for the full list of i.MX6 SLL clock IDs.
-
-Examples:
-
-#include <dt-bindings/clock/imx6sll-clock.h>
-
-clks: clock-controller@20c4000 {
- compatible = "fsl,imx6sll-ccm";
- reg = <0x020c4000 0x4000>;
- interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
- #clock-cells = <1>;
- clocks = <&ckil>, <&osc>, <&ipp_di0>, <&ipp_di1>;
- clock-names = "ckil", "osc", "ipp_di0", "ipp_di1";
-};
-
-uart1: serial@2020000 {
- compatible = "fsl,imx6sl-uart", "fsl,imx6q-uart", "fsl,imx21-uart";
- reg = <0x02020000 0x4000>;
- interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX6SLL_CLK_UART1_IPG>,
- <&clks IMX6SLL_CLK_UART1_SERIAL>;
- clock-names = "ipg", "per";
-};
diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml
new file mode 100644
index 0000000..fa55f1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx6sll-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX6 SLL
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx6sll-ccm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: CCM provides 2 interrupt requests, request 1 is to generate
+ interrupt for frequency or mux change, request 2 is to generate
+ interrupt for oscillator read or PLL lock.
+ items:
+ - description: CCM interrupt request 1
+ - description: CCM interrupt request 2
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: 32k osc
+ - description: 24m osc
+ - description: ipp_di0 clock input
+ - description: ipp_di1 clock input
+
+ clock-names:
+ items:
+ - const: ckil
+ - const: osc
+ - const: ipp_di0
+ - const: ipp_di1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+examples:
+ # Clock Control Module node:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@20c4000 {
+ compatible = "fsl,imx6sll-ccm";
+ reg = <0x020c4000 0x4000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ #clock-cells = <1>;
+ clocks = <&ckil>, <&osc>, <&ipp_di0>, <&ipp_di1>;
+ clock-names = "ckil", "osc", "ipp_di0", "ipp_di1";
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH V5 5/5] dt-bindings: clock: Convert i.MX6UL clock to json-schema
From: Anson Huang @ 2020-05-13 0:11 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
linux-clk, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1589328684-1397-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX6UL clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
Changes since V4:
- add descriptions for interrupts and each item of it.
---
.../devicetree/bindings/clock/imx6ul-clock.txt | 13 -----
.../devicetree/bindings/clock/imx6ul-clock.yaml | 66 ++++++++++++++++++++++
2 files changed, 66 insertions(+), 13 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx6ul-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx6ul-clock.txt b/Documentation/devicetree/bindings/clock/imx6ul-clock.txt
deleted file mode 100644
index 571d503..0000000
--- a/Documentation/devicetree/bindings/clock/imx6ul-clock.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-* Clock bindings for Freescale i.MX6 UltraLite
-
-Required properties:
-- compatible: Should be "fsl,imx6ul-ccm"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-- clocks: list of clock specifiers, must contain an entry for each required
- entry in clock-names
-- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6ul-clock.h
-for the full list of i.MX6 UltraLite clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
new file mode 100644
index 0000000..3c779ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx6ul-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX6 UltraLite
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx6ul-ccm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: CCM provides 2 interrupt requests, request 1 is to generate
+ interrupt for frequency or mux change, request 2 is to generate
+ interrupt for oscillator read or PLL lock.
+ items:
+ - description: CCM interrupt request 1
+ - description: CCM interrupt request 2
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: 32k osc
+ - description: 24m osc
+ - description: ipp_di0 clock input
+ - description: ipp_di1 clock input
+
+ clock-names:
+ items:
+ - const: ckil
+ - const: osc
+ - const: ipp_di0
+ - const: ipp_di1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+examples:
+ # Clock Control Module node:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@20c4000 {
+ compatible = "fsl,imx6ul-ccm";
+ reg = <0x020c4000 0x4000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ #clock-cells = <1>;
+ clocks = <&ckil>, <&osc>, <&ipp_di0>, <&ipp_di1>;
+ clock-names = "ckil", "osc", "ipp_di0", "ipp_di1";
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH V5 0/5] Convert i.MX6 SoCs clock bindings to json-schma
From: Anson Huang @ 2020-05-13 0:11 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
linux-clk, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
Converts i.MX6Q/i.MX6SX/i.MX6SL/i.MX6SLL/i.MX6UL clock bindings to
json-schma format.
Changes since V4:
- add descriptions for interrupts and each item of it.
Anson Huang (5):
dt-bindings: clock: Convert i.MX6Q clock to json-schema
dt-bindings: clock: Convert i.MX6SX clock to json-schema
dt-bindings: clock: Convert i.MX6SL clock to json-schema
dt-bindings: clock: Convert i.MX6SLL clock to json-schema
dt-bindings: clock: Convert i.MX6UL clock to json-schema
.../devicetree/bindings/clock/imx6q-clock.txt | 41 ------------
.../devicetree/bindings/clock/imx6q-clock.yaml | 72 ++++++++++++++++++++++
.../devicetree/bindings/clock/imx6sl-clock.txt | 10 ---
.../devicetree/bindings/clock/imx6sl-clock.yaml | 48 +++++++++++++++
.../devicetree/bindings/clock/imx6sll-clock.txt | 36 -----------
.../devicetree/bindings/clock/imx6sll-clock.yaml | 66 ++++++++++++++++++++
.../devicetree/bindings/clock/imx6sx-clock.txt | 13 ----
.../devicetree/bindings/clock/imx6sx-clock.yaml | 70 +++++++++++++++++++++
.../devicetree/bindings/clock/imx6ul-clock.txt | 13 ----
.../devicetree/bindings/clock/imx6ul-clock.yaml | 66 ++++++++++++++++++++
10 files changed, 322 insertions(+), 113 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx6q-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6q-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx6sx-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6sx-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx6ul-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
--
2.7.4
^ permalink raw reply
* Re: [PATCH v3 4/6] pstore/ram: Introduce max_reason and convert dump_oops
From: Kees Cook @ 2020-05-12 23:57 UTC (permalink / raw)
To: Tyler Hicks
Cc: Pavel Tatashin, Anton Vorontsov, Colin Cross, Tony Luck,
Jonathan Corbet, Rob Herring, Benson Leung,
Enric Balletbo i Serra, Petr Mladek, Sergey Senozhatsky,
Steven Rostedt, jmorris, sashal, linux-doc, linux-kernel,
devicetree
In-Reply-To: <20200512233504.GA118720@sequoia>
On Tue, May 12, 2020 at 06:35:04PM -0500, Tyler Hicks wrote:
> On 2020-05-06 14:15:21, Kees Cook wrote:
> > From: Pavel Tatashin <pasha.tatashin@soleen.com>
> >
> > Now that pstore_register() can correctly pass max_reason to the kmesg
> > dump facility, introduce a new "max_reason" module parameter and
> > "max-reason" Device Tree field.
> >
> > The "dump_oops" module parameter and "dump-oops" Device
> > Tree field are now considered deprecated, but are now automatically
> > converted to their corresponding max_reason values when present, though
> > the new max_reason setting has precedence.
> >
> > For struct ramoops_platform_data, the "dump_oops" member is entirely
> > replaced by a new "max_reason" member, with the only existing user
> > updated in place.
> >
> > Additionally remove the "reason" filter logic from ramoops_pstore_write(),
> > as that is not specifically needed anymore, though technically
> > this is a change in behavior for any ramoops users also setting the
> > printk.always_kmsg_dump boot param, which will cause ramoops to behave as
> > if max_reason was set to KMSG_DUMP_MAX.
> >
> > Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> > Link: https://lore.kernel.org/r/20200505154510.93506-4-pasha.tatashin@soleen.com
> > Link: https://lore.kernel.org/r/20200505154510.93506-5-pasha.tatashin@soleen.com
> > Co-developed-by: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > Documentation/admin-guide/ramoops.rst | 14 +++++--
> > drivers/platform/chrome/chromeos_pstore.c | 2 +-
> > fs/pstore/ram.c | 51 +++++++++++++++--------
> > include/linux/pstore_ram.h | 2 +-
> > 4 files changed, 45 insertions(+), 24 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/ramoops.rst b/Documentation/admin-guide/ramoops.rst
> > index 6dbcc5481000..a60a96218ba9 100644
> > --- a/Documentation/admin-guide/ramoops.rst
> > +++ b/Documentation/admin-guide/ramoops.rst
> > @@ -32,11 +32,17 @@ memory to be mapped strongly ordered, and atomic operations on strongly ordered
> > memory are implementation defined, and won't work on many ARMs such as omaps.
> >
> > The memory area is divided into ``record_size`` chunks (also rounded down to
> > -power of two) and each oops/panic writes a ``record_size`` chunk of
> > +power of two) and each kmesg dump writes a ``record_size`` chunk of
> > information.
> >
> > -Dumping both oopses and panics can be done by setting 1 in the ``dump_oops``
> > -variable while setting 0 in that variable dumps only the panics.
> > +Limiting which kinds of kmsg dumps are stored can be controlled via
> > +the ``max_reason`` value, as defined in include/linux/kmsg_dump.h's
> > +``enum kmsg_dump_reason``. For example, to store both Oopses and Panics,
> > +``max_reason`` should be set to 2 (KMSG_DUMP_OOPS), to store only Panics
> > +``max_reason`` should be set to 1 (KMSG_DUMP_PANIC). Setting this to 0
> > +(KMSG_DUMP_UNDEF), means the reason filtering will be controlled by the
> > +``printk.always_kmsg_dump`` boot param: if unset, it'll be KMSG_DUMP_OOPS,
> > +otherwise KMSG_DUMP_MAX.
> >
> > The module uses a counter to record multiple dumps but the counter gets reset
> > on restart (i.e. new dumps after the restart will overwrite old ones).
> > @@ -90,7 +96,7 @@ Setting the ramoops parameters can be done in several different manners:
> > .mem_address = <...>,
> > .mem_type = <...>,
> > .record_size = <...>,
> > - .dump_oops = <...>,
> > + .max_reason = <...>,
> > .ecc = <...>,
> > };
> >
> > diff --git a/drivers/platform/chrome/chromeos_pstore.c b/drivers/platform/chrome/chromeos_pstore.c
> > index d13770785fb5..fa51153688b4 100644
> > --- a/drivers/platform/chrome/chromeos_pstore.c
> > +++ b/drivers/platform/chrome/chromeos_pstore.c
> > @@ -57,7 +57,7 @@ static struct ramoops_platform_data chromeos_ramoops_data = {
> > .record_size = 0x40000,
> > .console_size = 0x20000,
> > .ftrace_size = 0x20000,
> > - .dump_oops = 1,
> > + .max_reason = KMSG_DUMP_OOPS,
> > };
> >
> > static struct platform_device chromeos_ramoops = {
> > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> > index c2f76b650f91..b8dac1d04e96 100644
> > --- a/fs/pstore/ram.c
> > +++ b/fs/pstore/ram.c
> > @@ -57,10 +57,15 @@ module_param(mem_type, uint, 0600);
> > MODULE_PARM_DESC(mem_type,
> > "set to 1 to try to use unbuffered memory (default 0)");
> >
> > -static int dump_oops = 1;
> > -module_param(dump_oops, int, 0600);
> > +static int ramoops_dump_oops = -1;
> > +module_param_named(dump_oops, ramoops_dump_oops, int, 0400);
> > MODULE_PARM_DESC(dump_oops,
> > - "set to 1 to dump oopses, 0 to only dump panics (default 1)");
> > + "set to 1 to dump oopses & panics, 0 to only dump panics (deprecated: use max_reason instead)");
> > +
> > +static int ramoops_max_reason = KMESG_DUMP_OOPS;
> > +module_param_named(max_reason, ramoops_max_reason, int, 0400);
> > +MODULE_PARM_DESC(max_reason,
> > + "maximum reason for kmsg dump (default 2: Oops and Panic) ");
> >
> > static int ramoops_ecc;
> > module_param_named(ecc, ramoops_ecc, int, 0600);
> > @@ -81,7 +86,6 @@ struct ramoops_context {
> > size_t console_size;
> > size_t ftrace_size;
> > size_t pmsg_size;
> > - int dump_oops;
> > u32 flags;
> > struct persistent_ram_ecc_info ecc_info;
> > unsigned int max_dump_cnt;
> > @@ -382,16 +386,14 @@ static int notrace ramoops_pstore_write(struct pstore_record *record)
> > return -EINVAL;
> >
> > /*
> > - * Out of the various dmesg dump types, ramoops is currently designed
> > - * to only store crash logs, rather than storing general kernel logs.
> > + * We could filter on record->reason here if we wanted to (which
> > + * would duplicate what happened before the "max_reason" setting
> > + * was added), but that would defeat the purpose of a system
> > + * changing printk.always_kmsg_dump, so instead log everything that
> > + * the kmsg dumper sends us, since it should be doing the filtering
> > + * based on the combination of printk.always_kmsg_dump and our
> > + * requested "max_reason".
> > */
> > - if (record->reason != KMSG_DUMP_OOPS &&
> > - record->reason != KMSG_DUMP_PANIC)
> > - return -EINVAL;
> > -
> > - /* Skip Oopes when configured to do so. */
> > - if (record->reason == KMSG_DUMP_OOPS && !cxt->dump_oops)
> > - return -EINVAL;
> >
> > /*
> > * Explicitly only take the first part of any new crash.
> > @@ -692,7 +694,14 @@ static int ramoops_parse_dt(struct platform_device *pdev,
> > pdata->mem_size = resource_size(res);
> > pdata->mem_address = res->start;
> > pdata->mem_type = of_property_read_bool(of_node, "unbuffered");
> > - pdata->dump_oops = !of_property_read_bool(of_node, "no-dump-oops");
> > + /*
> > + * Setting "no-dump-oops" is deprecated and will be ignored if
> > + * "max_reason" is also specified.
> > + */
> > + if (of_property_read_bool(of_node, "no-dump-oops"))
> > + pdata->max_reason = KMSG_DUMP_PANIC;
> > + else
> > + pdata->max_reason = KMSG_DUMP_OOPS;
> >
> > #define parse_size(name, field, default_value) { \
> > ret = ramoops_parse_dt_size(pdev, name, default_value, \
> > @@ -708,6 +717,7 @@ static int ramoops_parse_dt(struct platform_device *pdev,
> > parse_size("pmsg-size", pdata->pmsg_size, 0);
> > parse_size("ecc-size", pdata->ecc_info.ecc_size, 0);
> > parse_size("flags", pdata->flags, 0);
> > + parse_size("max-reason", pdata->max_reason, pdata->max_reason);
> >
> > #undef parse_size
> >
> > @@ -791,7 +801,6 @@ static int ramoops_probe(struct platform_device *pdev)
> > cxt->console_size = pdata->console_size;
> > cxt->ftrace_size = pdata->ftrace_size;
> > cxt->pmsg_size = pdata->pmsg_size;
> > - cxt->dump_oops = pdata->dump_oops;
> > cxt->flags = pdata->flags;
> > cxt->ecc_info = pdata->ecc_info;
> >
> > @@ -834,8 +843,10 @@ static int ramoops_probe(struct platform_device *pdev)
> > * the single region size is how to check.
> > */
> > cxt->pstore.flags = 0;
> > - if (cxt->max_dump_cnt)
> > + if (cxt->max_dump_cnt) {
> > cxt->pstore.flags |= PSTORE_FLAGS_DMESG;
> > + cxt->pstore.max_reason = pdata->max_reason;
> > + }
> > if (cxt->console_size)
> > cxt->pstore.flags |= PSTORE_FLAGS_CONSOLE;
> > if (cxt->max_ftrace_cnt)
> > @@ -871,7 +882,7 @@ static int ramoops_probe(struct platform_device *pdev)
> > mem_size = pdata->mem_size;
> > mem_address = pdata->mem_address;
> > record_size = pdata->record_size;
> > - dump_oops = pdata->dump_oops;
> > + ramoops_max_reason = pdata->max_reason;
> > ramoops_console_size = pdata->console_size;
> > ramoops_pmsg_size = pdata->pmsg_size;
> > ramoops_ftrace_size = pdata->ftrace_size;
> > @@ -954,7 +965,11 @@ static void __init ramoops_register_dummy(void)
> > pdata.console_size = ramoops_console_size;
> > pdata.ftrace_size = ramoops_ftrace_size;
> > pdata.pmsg_size = ramoops_pmsg_size;
> > - pdata.dump_oops = dump_oops;
> > + /* Parse deprecated module param "dump_oops" into "max_reason". */
> > + if (ramoops_dump_oops != -1)
> > + pdata.max_reason = ramoops_dump_oops ? KMSG_DUMP_OOPS
> > + : KMSG_DUMP_PANIC;
> > + pdata.max_reason = ramoops_max_reason;
>
> This isn't quite right. We're conditionally assigning pdata.max_reason
> and then immediately re-assigning it.
>
> IIUC, we're just missing an else block and it should look like this:
>
> /* Parse deprecated module param "dump_oops" into "max_reason". */
> if (ramoops_dump_oops != -1)
> pdata.max_reason = ramoops_dump_oops ? KMSG_DUMP_OOPS
> : KMSG_DUMP_PANIC;
> else
> pdata.max_reason = ramoops_max_reason;
Oops, yes. ramoops_max_reason needs to also have an "unset" value so
this can determine which was set... I'll get this fixed. Thanks for
double-checking this!
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3 4/6] pstore/ram: Introduce max_reason and convert dump_oops
From: Tyler Hicks @ 2020-05-12 23:35 UTC (permalink / raw)
To: Kees Cook
Cc: Pavel Tatashin, Anton Vorontsov, Colin Cross, Tony Luck,
Jonathan Corbet, Rob Herring, Benson Leung,
Enric Balletbo i Serra, Petr Mladek, Sergey Senozhatsky,
Steven Rostedt, jmorris, sashal, linux-doc, linux-kernel,
devicetree
In-Reply-To: <20200506211523.15077-5-keescook@chromium.org>
On 2020-05-06 14:15:21, Kees Cook wrote:
> From: Pavel Tatashin <pasha.tatashin@soleen.com>
>
> Now that pstore_register() can correctly pass max_reason to the kmesg
> dump facility, introduce a new "max_reason" module parameter and
> "max-reason" Device Tree field.
>
> The "dump_oops" module parameter and "dump-oops" Device
> Tree field are now considered deprecated, but are now automatically
> converted to their corresponding max_reason values when present, though
> the new max_reason setting has precedence.
>
> For struct ramoops_platform_data, the "dump_oops" member is entirely
> replaced by a new "max_reason" member, with the only existing user
> updated in place.
>
> Additionally remove the "reason" filter logic from ramoops_pstore_write(),
> as that is not specifically needed anymore, though technically
> this is a change in behavior for any ramoops users also setting the
> printk.always_kmsg_dump boot param, which will cause ramoops to behave as
> if max_reason was set to KMSG_DUMP_MAX.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> Link: https://lore.kernel.org/r/20200505154510.93506-4-pasha.tatashin@soleen.com
> Link: https://lore.kernel.org/r/20200505154510.93506-5-pasha.tatashin@soleen.com
> Co-developed-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> Documentation/admin-guide/ramoops.rst | 14 +++++--
> drivers/platform/chrome/chromeos_pstore.c | 2 +-
> fs/pstore/ram.c | 51 +++++++++++++++--------
> include/linux/pstore_ram.h | 2 +-
> 4 files changed, 45 insertions(+), 24 deletions(-)
>
> diff --git a/Documentation/admin-guide/ramoops.rst b/Documentation/admin-guide/ramoops.rst
> index 6dbcc5481000..a60a96218ba9 100644
> --- a/Documentation/admin-guide/ramoops.rst
> +++ b/Documentation/admin-guide/ramoops.rst
> @@ -32,11 +32,17 @@ memory to be mapped strongly ordered, and atomic operations on strongly ordered
> memory are implementation defined, and won't work on many ARMs such as omaps.
>
> The memory area is divided into ``record_size`` chunks (also rounded down to
> -power of two) and each oops/panic writes a ``record_size`` chunk of
> +power of two) and each kmesg dump writes a ``record_size`` chunk of
> information.
>
> -Dumping both oopses and panics can be done by setting 1 in the ``dump_oops``
> -variable while setting 0 in that variable dumps only the panics.
> +Limiting which kinds of kmsg dumps are stored can be controlled via
> +the ``max_reason`` value, as defined in include/linux/kmsg_dump.h's
> +``enum kmsg_dump_reason``. For example, to store both Oopses and Panics,
> +``max_reason`` should be set to 2 (KMSG_DUMP_OOPS), to store only Panics
> +``max_reason`` should be set to 1 (KMSG_DUMP_PANIC). Setting this to 0
> +(KMSG_DUMP_UNDEF), means the reason filtering will be controlled by the
> +``printk.always_kmsg_dump`` boot param: if unset, it'll be KMSG_DUMP_OOPS,
> +otherwise KMSG_DUMP_MAX.
>
> The module uses a counter to record multiple dumps but the counter gets reset
> on restart (i.e. new dumps after the restart will overwrite old ones).
> @@ -90,7 +96,7 @@ Setting the ramoops parameters can be done in several different manners:
> .mem_address = <...>,
> .mem_type = <...>,
> .record_size = <...>,
> - .dump_oops = <...>,
> + .max_reason = <...>,
> .ecc = <...>,
> };
>
> diff --git a/drivers/platform/chrome/chromeos_pstore.c b/drivers/platform/chrome/chromeos_pstore.c
> index d13770785fb5..fa51153688b4 100644
> --- a/drivers/platform/chrome/chromeos_pstore.c
> +++ b/drivers/platform/chrome/chromeos_pstore.c
> @@ -57,7 +57,7 @@ static struct ramoops_platform_data chromeos_ramoops_data = {
> .record_size = 0x40000,
> .console_size = 0x20000,
> .ftrace_size = 0x20000,
> - .dump_oops = 1,
> + .max_reason = KMSG_DUMP_OOPS,
> };
>
> static struct platform_device chromeos_ramoops = {
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index c2f76b650f91..b8dac1d04e96 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -57,10 +57,15 @@ module_param(mem_type, uint, 0600);
> MODULE_PARM_DESC(mem_type,
> "set to 1 to try to use unbuffered memory (default 0)");
>
> -static int dump_oops = 1;
> -module_param(dump_oops, int, 0600);
> +static int ramoops_dump_oops = -1;
> +module_param_named(dump_oops, ramoops_dump_oops, int, 0400);
> MODULE_PARM_DESC(dump_oops,
> - "set to 1 to dump oopses, 0 to only dump panics (default 1)");
> + "set to 1 to dump oopses & panics, 0 to only dump panics (deprecated: use max_reason instead)");
> +
> +static int ramoops_max_reason = KMESG_DUMP_OOPS;
> +module_param_named(max_reason, ramoops_max_reason, int, 0400);
> +MODULE_PARM_DESC(max_reason,
> + "maximum reason for kmsg dump (default 2: Oops and Panic) ");
>
> static int ramoops_ecc;
> module_param_named(ecc, ramoops_ecc, int, 0600);
> @@ -81,7 +86,6 @@ struct ramoops_context {
> size_t console_size;
> size_t ftrace_size;
> size_t pmsg_size;
> - int dump_oops;
> u32 flags;
> struct persistent_ram_ecc_info ecc_info;
> unsigned int max_dump_cnt;
> @@ -382,16 +386,14 @@ static int notrace ramoops_pstore_write(struct pstore_record *record)
> return -EINVAL;
>
> /*
> - * Out of the various dmesg dump types, ramoops is currently designed
> - * to only store crash logs, rather than storing general kernel logs.
> + * We could filter on record->reason here if we wanted to (which
> + * would duplicate what happened before the "max_reason" setting
> + * was added), but that would defeat the purpose of a system
> + * changing printk.always_kmsg_dump, so instead log everything that
> + * the kmsg dumper sends us, since it should be doing the filtering
> + * based on the combination of printk.always_kmsg_dump and our
> + * requested "max_reason".
> */
> - if (record->reason != KMSG_DUMP_OOPS &&
> - record->reason != KMSG_DUMP_PANIC)
> - return -EINVAL;
> -
> - /* Skip Oopes when configured to do so. */
> - if (record->reason == KMSG_DUMP_OOPS && !cxt->dump_oops)
> - return -EINVAL;
>
> /*
> * Explicitly only take the first part of any new crash.
> @@ -692,7 +694,14 @@ static int ramoops_parse_dt(struct platform_device *pdev,
> pdata->mem_size = resource_size(res);
> pdata->mem_address = res->start;
> pdata->mem_type = of_property_read_bool(of_node, "unbuffered");
> - pdata->dump_oops = !of_property_read_bool(of_node, "no-dump-oops");
> + /*
> + * Setting "no-dump-oops" is deprecated and will be ignored if
> + * "max_reason" is also specified.
> + */
> + if (of_property_read_bool(of_node, "no-dump-oops"))
> + pdata->max_reason = KMSG_DUMP_PANIC;
> + else
> + pdata->max_reason = KMSG_DUMP_OOPS;
>
> #define parse_size(name, field, default_value) { \
> ret = ramoops_parse_dt_size(pdev, name, default_value, \
> @@ -708,6 +717,7 @@ static int ramoops_parse_dt(struct platform_device *pdev,
> parse_size("pmsg-size", pdata->pmsg_size, 0);
> parse_size("ecc-size", pdata->ecc_info.ecc_size, 0);
> parse_size("flags", pdata->flags, 0);
> + parse_size("max-reason", pdata->max_reason, pdata->max_reason);
>
> #undef parse_size
>
> @@ -791,7 +801,6 @@ static int ramoops_probe(struct platform_device *pdev)
> cxt->console_size = pdata->console_size;
> cxt->ftrace_size = pdata->ftrace_size;
> cxt->pmsg_size = pdata->pmsg_size;
> - cxt->dump_oops = pdata->dump_oops;
> cxt->flags = pdata->flags;
> cxt->ecc_info = pdata->ecc_info;
>
> @@ -834,8 +843,10 @@ static int ramoops_probe(struct platform_device *pdev)
> * the single region size is how to check.
> */
> cxt->pstore.flags = 0;
> - if (cxt->max_dump_cnt)
> + if (cxt->max_dump_cnt) {
> cxt->pstore.flags |= PSTORE_FLAGS_DMESG;
> + cxt->pstore.max_reason = pdata->max_reason;
> + }
> if (cxt->console_size)
> cxt->pstore.flags |= PSTORE_FLAGS_CONSOLE;
> if (cxt->max_ftrace_cnt)
> @@ -871,7 +882,7 @@ static int ramoops_probe(struct platform_device *pdev)
> mem_size = pdata->mem_size;
> mem_address = pdata->mem_address;
> record_size = pdata->record_size;
> - dump_oops = pdata->dump_oops;
> + ramoops_max_reason = pdata->max_reason;
> ramoops_console_size = pdata->console_size;
> ramoops_pmsg_size = pdata->pmsg_size;
> ramoops_ftrace_size = pdata->ftrace_size;
> @@ -954,7 +965,11 @@ static void __init ramoops_register_dummy(void)
> pdata.console_size = ramoops_console_size;
> pdata.ftrace_size = ramoops_ftrace_size;
> pdata.pmsg_size = ramoops_pmsg_size;
> - pdata.dump_oops = dump_oops;
> + /* Parse deprecated module param "dump_oops" into "max_reason". */
> + if (ramoops_dump_oops != -1)
> + pdata.max_reason = ramoops_dump_oops ? KMSG_DUMP_OOPS
> + : KMSG_DUMP_PANIC;
> + pdata.max_reason = ramoops_max_reason;
This isn't quite right. We're conditionally assigning pdata.max_reason
and then immediately re-assigning it.
IIUC, we're just missing an else block and it should look like this:
/* Parse deprecated module param "dump_oops" into "max_reason". */
if (ramoops_dump_oops != -1)
pdata.max_reason = ramoops_dump_oops ? KMSG_DUMP_OOPS
: KMSG_DUMP_PANIC;
else
pdata.max_reason = ramoops_max_reason;
Tyler
> pdata.flags = RAMOOPS_FLAG_FTRACE_PER_CPU;
>
> /*
> diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h
> index 9cb9b9067298..9f16afec7290 100644
> --- a/include/linux/pstore_ram.h
> +++ b/include/linux/pstore_ram.h
> @@ -133,7 +133,7 @@ struct ramoops_platform_data {
> unsigned long console_size;
> unsigned long ftrace_size;
> unsigned long pmsg_size;
> - int dump_oops;
> + int max_reason;
> u32 flags;
> struct persistent_ram_ecc_info ecc_info;
> };
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: renesas: div6: Convert to json-schema
From: Stephen Boyd @ 2020-05-12 23:27 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Rob Herring
Cc: devicetree, linux-clk, linux-renesas-soc, Geert Uytterhoeven
In-Reply-To: <20200507075026.31941-1-geert+renesas@glider.be>
Quoting Geert Uytterhoeven (2020-05-07 00:50:26)
> Convert the Renesas CPG DIV6 Clock Device Tree binding documentation to
> json-schema.
>
> Drop R-Car Gen2 compatible values, which were obsoleted by the unified
> "Renesas Clock Pulse Generator / Module Standby and Software Reset" DT
> bindings.
> Update the example to match reality.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: gpio-vibrator: Don't require enable-gpios
From: Dmitry Torokhov @ 2020-05-12 23:25 UTC (permalink / raw)
To: Ondřej Jirman, linux-sunxi, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Luca Weiss, Tomas Novotny,
linux-input, devicetree, linux-kernel, linux-arm-kernel,
Rob Herring
In-Reply-To: <20200512230557.zvdgwhbqygc2fufv@core.my.home>
On Wed, May 13, 2020 at 01:05:57AM +0200, Ondřej Jirman wrote:
> On Tue, May 12, 2020 at 03:52:12PM -0700, Dmitry Torokhov wrote:
> > On Wed, May 13, 2020 at 12:22:02AM +0200, Ondrej Jirman wrote:
> > > It is possible to turn the motor on/off just by enabling/disabling
> > > the vcc-supply.
> > >
> > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > Acked-by: Rob Herring <robh@kernel.org>
> > > ---
> > > Documentation/devicetree/bindings/input/gpio-vibrator.yaml | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/gpio-vibrator.yaml b/Documentation/devicetree/bindings/input/gpio-vibrator.yaml
> > > index 2384465eaa19..c700b640bd53 100644
> > > --- a/Documentation/devicetree/bindings/input/gpio-vibrator.yaml
> > > +++ b/Documentation/devicetree/bindings/input/gpio-vibrator.yaml
> > > @@ -24,7 +24,6 @@ properties:
> > >
> > > required:
> > > - compatible
> > > - - enable-gpios
> >
> > Hmm we need at least one of the 2 (gpio and supply). Should we encode it
> > in the binding?
>
> Not sure how to encode either one or the other property being required, but
> not both at once.
>
> Maybe I can add a supply-vibrator compatible to the driver and binding and
> make requirements dependent on the compatible?
Rob is our bindings overlord... I'll defer to him here.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Add ch7322 as a trivial device
From: Jeff Chase @ 2020-05-12 23:23 UTC (permalink / raw)
To: Rob Herring; +Cc: linux-media, mchehab, Hans Verkuil, devicetree
In-Reply-To: <20200511212047.GA21845@bogus>
On Mon, May 11, 2020 at 5:20 PM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, Apr 24, 2020 at 01:38:18AM -0400, Jeff Chase wrote:
> > The ch7322 is a Chrontel CEC controller.
> >
> > Signed-off-by: Jeff Chase <jnchase@google.com>
> > ---
> > Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
> > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> > index 4165352a590a..ec2ddc6cdf9a 100644
> > --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> > @@ -48,6 +48,8 @@ properties:
> > - capella,cm32181
> > # CM3232: Ambient Light Sensor
> > - capella,cm3232
> > + # CH7322: HDMI-CEC Controller
> > + - chrontel,ch7322
>
> I don't think this qualifies as a trivial device. It has HPDI, OE and
> reset signals all likely hooked up to GPIOs. You might not have those
> hooked up for s/w control, but someone will.
>
> And I'd assume if you had multiple instances, they will need to be
> associated with each connector.
>
> Rob
Thank you for looking at this. Taking a step back for a moment, I am
developing this driver for an x86/ACPI platform on which I also
control the firmware. Is there a preference between using an ACPI ID
and a devicetree compatible id? I am trying to find out if the vendor
already has an ACPI ID for this device. If I find and use that should
I still add a compatible id anyways?
Jeff
^ permalink raw reply
* Re: [RFC][PATCH 1/2] Add a layer of abstraction to use the memory reserved by device tree for ima buffer pass.
From: Rob Herring @ 2020-05-12 23:09 UTC (permalink / raw)
To: Prakhar Srivastava
Cc: linux-arm-kernel, linux-kernel, linuxppc-dev, devicetree,
linux-integrity, linux-security-module, catalin.marinas, will,
mpe, benh, paulus, frowand.list, zohar, dmitry.kasatkin, jmorris,
serge, pasha.tatashin, allison, kstewart, takahiro.akashi, tglx,
vincenzo.frascino, mark.rutland, masahiroy, james.morse, bhsharma,
mbrugger, hsinyi, tao.li, christophe.leroy, gregkh, nramas,
tusharsu, balajib
In-Reply-To: <20200504203829.6330-2-prsriva@linux.microsoft.com>
On Mon, May 04, 2020 at 01:38:28PM -0700, Prakhar Srivastava wrote:
> Introduce a device tree layer for to read and store ima buffer
> from the reserved memory section of a device tree.
But why do I need 'a layer of abstraction'? I don't like them.
> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
> ---
> drivers/of/Kconfig | 6 ++
> drivers/of/Makefile | 1 +
> drivers/of/of_ima.c | 165 ++++++++++++++++++++++++++++++++++++++++++++
Who are the users of this code and why does it need to be here? Most
code for specific bindings are not in drivers/of/ but with the user. It
doesn't sound like there's more than 1 user.
> include/linux/of.h | 34 +++++++++
> 4 files changed, 206 insertions(+)
> create mode 100644 drivers/of/of_ima.c
^ 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