Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver
From: Łukasz Stelmach @ 2017-12-22 16:38 UTC (permalink / raw)
  To: Philippe Ombredanne
  Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
	Matt Mackall, Herbert Xu, Krzysztof Kozlowski, Kukjin Kim,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-crypto, linux-samsung-soc, LKML, Marek Szyprowski,
	Bartlomiej Zolnierkiewicz
In-Reply-To: <CAOFm3uG2aBHWUgVyzPuU8XJaLbm78cWEuWvgLEvNfc-hiefAbw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

It was <2017-12-22 pią 14:34>, when Philippe Ombredanne wrote:
> Łukasz,
>
> On Fri, Dec 22, 2017 at 2:23 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
>> Add support for True Random Number Generator found in Samsung Exynos
>> 5250+ SoCs.
>>
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> <snip>
>
>> --- /dev/null
>> +++ b/drivers/char/hw_random/exynos-trng.c
>> @@ -0,0 +1,245 @@
>> +/*
>> + * RNG driver for Exynos TRNGs
>> + *
>> + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
>> + *
>> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
>> + *
>> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
>> + * Krzysztof Kozłowski <krzk@kernel.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation;
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>
>
> Would you mind using the new SPDX tags documented in Thomas patch set
> [1] rather than this fine but longer legalese?
>
> And if you could spread the word to others in your team this would be very nice.
> See also this fine article posted by Mauro on the Samsung Open Source
> Group Blog [2]
> Thank you!

Cool! We've been using SPDX to tag RPM packages in Tizen for three years or
more. ;-)

>> +MODULE_LICENSE("GPL");
>
> Per module.h this means GPL2 or later. This is not matching your
> license above which does not state any version and therefore would
> mean GPL1 or later,

Thanks for spotting. My intention is GPL-2.0.

> Please make sure you use something and common rather than this and
> make sure your MODULE_LICENSE is consistent with the top level
> license.
>
> Was it this way in the code from Krzysztof?

Yes. And omap-rng, the second of my sources of reference, too. Actually,
the majority of modules still specify "GPL".

 281 | "Dual */*"
2082 | "GPL v2"
6359 | "GPL"
---- +---------
8784 | Total

Fixing.

> [1] https://lkml.org/lkml/2017/12/4/934
> [2] https://blogs.s-osg.org/linux-kernel-license-practices-revisited-spdx/

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

^ permalink raw reply

* [PATCH v5] hwrng: exynos - add Samsung Exynos True RNG driver
From: Łukasz Stelmach @ 2017-12-22 16:48 UTC (permalink / raw)
  To: Philippe Ombredanne, Andrew F . Davis, PrasannaKumar Muralidharan,
	Rob Herring, Matt Mackall, Herbert Xu, Krzysztof Kozlowski,
	Kukjin Kim, devicetree, linux-crypto, linux-samsung-soc,
	linux-kernel
  Cc: Łukasz Stelmach, Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20171222132338.30054-1-l.stelmach@samsung.com>

Add support for True Random Number Generator found in Samsung Exynos
5250+ SoCs.

Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v4:
 
- SPDX license header instead of the traditional blurb.

- MODULE_LICENSE("GPL v2") instead of "GPL"
 
Thank you, Philippe Ombredanne.

 MAINTAINERS                          |   7 ++
 drivers/char/hw_random/Kconfig       |  12 ++
 drivers/char/hw_random/Makefile      |   1 +
 drivers/char/hw_random/exynos-trng.c | 237 +++++++++++++++++++++++++++++++++++
 4 files changed, 257 insertions(+)
 create mode 100644 drivers/char/hw_random/exynos-trng.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e6d849d0d153..1082846edb9b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11933,6 +11933,13 @@ S:	Maintained
 F:	drivers/crypto/exynos-rng.c
 F:	Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
 
+SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER
+M:	Łukasz Stelmach <l.stelmach@samsung.com>
+L:	linux-samsung-soc@vger.kernel.org
+S:	Maintained
+F:	drivers/char/hw_random/exynos-trng.c
+F:	Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
+
 SAMSUNG FRAMEBUFFER DRIVER
 M:	Jingoo Han <jingoohan1@gmail.com>
 L:	linux-fbdev@vger.kernel.org
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 90e4bb24819e..32f715394904 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -437,6 +437,18 @@ config HW_RANDOM_S390
 
 	  If unsure, say Y.
 
+config HW_RANDOM_EXYNOS
+	tristate "Samsung Exynos True Random Number Generator support"
+	depends on ARCH_EXYNOS || COMPILE_TEST
+	default HW_RANDOM
+	---help---
+	  This driver provides support for the True Random Number
+	  Generator available in Exynos SoCs.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called exynos-trng.
+
+	  If unsure, say Y.
 endif # HW_RANDOM
 
 config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index e7146a84d44a..7c8a66fe8cf6 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_HW_RANDOM_GEODE) += geode-rng.o
 obj-$(CONFIG_HW_RANDOM_N2RNG) += n2-rng.o
 n2-rng-y := n2-drv.o n2-asm.o
 obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
+obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-trng.o
 obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
 obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
 obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
new file mode 100644
index 000000000000..34d6f51ecbee
--- /dev/null
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RNG driver for Exynos TRNGs
+ *
+ * Author: Łukasz Stelmach <l.stelmach@samsung.com>
+ *
+ * Copyright 2017 (c) Samsung Electronics Software, Inc.
+ *
+ * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
+ * Krzysztof Kozłowski <krzk@kernel.org>
+ */
+
+#include <linux/clk.h>
+#include <linux/crypto.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#define EXYNOS_TRNG_CLKDIV         (0x0)
+
+#define EXYNOS_TRNG_CTRL           (0x20)
+#define EXYNOS_TRNG_CTRL_RNGEN     BIT(31)
+
+#define EXYNOS_TRNG_POST_CTRL      (0x30)
+#define EXYNOS_TRNG_ONLINE_CTRL    (0x40)
+#define EXYNOS_TRNG_ONLINE_STAT    (0x44)
+#define EXYNOS_TRNG_ONLINE_MAXCHI2 (0x48)
+#define EXYNOS_TRNG_FIFO_CTRL      (0x50)
+#define EXYNOS_TRNG_FIFO_0         (0x80)
+#define EXYNOS_TRNG_FIFO_1         (0x84)
+#define EXYNOS_TRNG_FIFO_2         (0x88)
+#define EXYNOS_TRNG_FIFO_3         (0x8c)
+#define EXYNOS_TRNG_FIFO_4         (0x90)
+#define EXYNOS_TRNG_FIFO_5         (0x94)
+#define EXYNOS_TRNG_FIFO_6         (0x98)
+#define EXYNOS_TRNG_FIFO_7         (0x9c)
+#define EXYNOS_TRNG_FIFO_LEN       (8)
+#define EXYNOS_TRNG_CLOCK_RATE     (500000)
+
+
+struct exynos_trng_dev {
+	struct device    *dev;
+	void __iomem     *mem;
+	struct clk       *clk;
+	struct hwrng rng;
+};
+
+static int exynos_trng_do_read(struct hwrng *rng, void *data, size_t max,
+			       bool wait)
+{
+	struct exynos_trng_dev *trng;
+	u32 val;
+
+	max = min_t(size_t, max, (EXYNOS_TRNG_FIFO_LEN * 4));
+
+	trng = (struct exynos_trng_dev *)rng->priv;
+
+	writel_relaxed(max * 8, trng->mem + EXYNOS_TRNG_FIFO_CTRL);
+	val = readl_poll_timeout(trng->mem + EXYNOS_TRNG_FIFO_CTRL, val,
+				 val == 0, 200, 1000000);
+	if (val < 0)
+		return val;
+
+	memcpy_fromio(data, trng->mem + EXYNOS_TRNG_FIFO_0, max);
+
+	return max;
+}
+
+static int exynos_trng_init(struct hwrng *rng)
+{
+	struct exynos_trng_dev *trng = (struct exynos_trng_dev *)rng->priv;
+	unsigned long sss_rate;
+	u32 val;
+
+	sss_rate = clk_get_rate(trng->clk);
+
+	/*
+	 * For most TRNG circuits the clock frequency of under 500 kHz
+	 * is safe.
+	 */
+	val = sss_rate / (EXYNOS_TRNG_CLOCK_RATE * 2);
+	if (val > 0x7fff) {
+		dev_err(trng->dev, "clock divider too large: %d", val);
+		return -ERANGE;
+	}
+	val = val << 1;
+	writel_relaxed(val, trng->mem + EXYNOS_TRNG_CLKDIV);
+
+	/* Enable the generator. */
+	val = EXYNOS_TRNG_CTRL_RNGEN;
+	writel_relaxed(val, trng->mem + EXYNOS_TRNG_CTRL);
+
+	/*
+	 * Disable post-processing. /dev/hwrng is supposed to deliver
+	 * unprocessed data.
+	 */
+	writel_relaxed(0, trng->mem + EXYNOS_TRNG_POST_CTRL);
+
+	return 0;
+}
+
+static int exynos_trng_probe(struct platform_device *pdev)
+{
+	struct exynos_trng_dev *trng;
+	struct resource *res;
+	int ret = -ENOMEM;
+
+	trng = devm_kzalloc(&pdev->dev, sizeof(*trng), GFP_KERNEL);
+	if (!trng)
+		return ret;
+
+	trng->rng.name = devm_kstrdup(&pdev->dev, dev_name(&pdev->dev),
+				      GFP_KERNEL);
+	if (!trng->rng.name)
+		return ret;
+
+	trng->rng.init = exynos_trng_init;
+	trng->rng.read = exynos_trng_do_read;
+	trng->rng.priv = (unsigned long) trng;
+
+	platform_set_drvdata(pdev, trng);
+	trng->dev = &pdev->dev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	trng->mem = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(trng->mem)) {
+		dev_err(&pdev->dev, "Could not map IO resources.\n");
+		return PTR_ERR(trng->mem);
+	}
+
+	pm_runtime_enable(&pdev->dev);
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Could not get runtime PM.\n");
+		goto err_pm_get;
+	}
+
+	trng->clk = devm_clk_get(&pdev->dev, "secss");
+	if (IS_ERR(trng->clk)) {
+		ret = PTR_ERR(trng->clk);
+		dev_err(&pdev->dev, "Could not get clock.\n");
+		goto err_clock;
+	}
+
+	ret = clk_prepare_enable(trng->clk);
+	if (ret) {
+		dev_err(&pdev->dev, "Could not enable the clk.\n");
+		goto err_clock;
+	}
+
+	ret = hwrng_register(&trng->rng);
+	if (ret) {
+		dev_err(&pdev->dev, "Could not register hwrng device.\n");
+		goto err_register;
+	}
+
+	dev_info(&pdev->dev, "Exynos True Random Number Generator.\n");
+
+	return 0;
+
+err_register:
+	clk_disable_unprepare(trng->clk);
+
+err_clock:
+	pm_runtime_put_sync(&pdev->dev);
+
+err_pm_get:
+	pm_runtime_disable(&pdev->dev);
+
+	return ret;
+}
+
+static int exynos_trng_remove(struct platform_device *pdev)
+{
+	struct exynos_trng_dev *trng =  platform_get_drvdata(pdev);
+
+	hwrng_unregister(&trng->rng);
+	clk_disable_unprepare(trng->clk);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+
+	return 0;
+}
+
+static int __maybe_unused exynos_trng_suspend(struct device *dev)
+{
+	pm_runtime_put_sync(dev);
+
+	return 0;
+}
+
+static int __maybe_unused exynos_trng_resume(struct device *dev)
+{
+	int ret;
+
+	ret = pm_runtime_get_sync(dev);
+	if (ret < 0) {
+		dev_err(dev, "Could not get runtime PM.\n");
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(exynos_trng_pm_ops, exynos_trng_suspend,
+			 exynos_trng_resume);
+
+static const struct of_device_id exynos_trng_dt_match[] = {
+	{
+		.compatible = "samsung,exynos5250-trng",
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, exynos_trng_dt_match);
+
+static struct platform_driver exynos_trng_driver = {
+	.driver = {
+		.name = "exynos-trng",
+		.pm = &exynos_trng_pm_ops,
+		.of_match_table = exynos_trng_dt_match,
+	},
+	.probe = exynos_trng_probe,
+	.remove = exynos_trng_remove,
+};
+
+module_platform_driver(exynos_trng_driver);
+MODULE_AUTHOR("Łukasz Stelmach");
+MODULE_DESCRIPTION("H/W TRNG driver for Exynos chips");
+MODULE_LICENSE("GPL v2");
-- 
2.11.0

^ permalink raw reply related

* Re: [PATCH v2 1/5] dt-bindings: at24: consistently document the compatible property
From: Peter Rosin @ 2017-12-22 16:58 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: Bartosz Golaszewski, Andy Shevchenko, Rob Herring, Mark Rutland,
	David Lechner, Divagar Mohandass, Linux I2C,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Linux Kernel
In-Reply-To: <CABxcv=kkp_Ck_JdDGomAGmSsTiCg82X67j5hEsvRnnY3RDMMfg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 2017-12-22 00:38, Javier Martinez Canillas wrote:
> Hello Peter,
> 
> On Fri, Dec 22, 2017 at 12:07 AM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>> On 2017-12-21 21:27, Javier Martinez Canillas wrote:
>>> Hello Peter,
>>>
>>> On Thu, Dec 21, 2017 at 5:20 PM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>>>> On 2017-12-21 14:48, Bartosz Golaszewski wrote:
>>>>> Current description of the compatible property for at24 is quite vague.
>>>>>
>>>>> Specify an exact list of accepted compatibles and document the - now
>>>>> deprecated - strings which were previously used in device tree files.
>>>>
>>>> Why is it suddenly deprecated to correctly specify what hardware you
>>>> have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.
>>>
>>> Sorry but I disagree.
>>>
>>> When you specify a compatible string, you are not specifying a
>>> particular hardware but a device programming model.
>>
>> That's not what it says in https://elinux.org/Device_Tree_Usage
> 
> I think the most up-to-date DT reference is at:
> 
> https://www.devicetree.org/
> 
>> in the "Understanding the compatible Property" section. I quote:
>>
>>         compatible is a list of strings. The first string in the
>>         list specifies the exact device that the node represents
>>         in the form "<manufacturer>,<model>". The following strings
>>         represent other devices that the device is compatible with.
>>
>> Pretty clearly talks about devices and not programming models. But
>> maybe I shouldn't trust that reference? What should I be reading
>> instead?
>>
> 
> For example the latest spec draft
> (https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2-rc1/devicetree-specification-v0.2-rc1.pdf)
> says:
> 
> "The compatible property value consists of one or more strings that
> define the specific programming model for the device. This list of
> strings should be used by a client program for device driver
> selection. The property value consists of a concatenated list of null
> terminated strings, from most specific to most general. They allow a
> device to express its compatibility with a family of similar devices,
> potentially allowing a single device driver to match against several
> devices."
> 
> The recommended format is "manufacturer,model", where manufacturer is
> a string describing the name of the manufacturer (such as a stock
> ticker symbol), and model specifies the model number."
> 
> Example:
> 
> compatible = "fsl,mpc8641", "ns16550";
> 
> In this example, an operating system would first try to locate a
> device driver that supported fsl,mpc8641. If a driver was not found,
> it would then try to locate a driver that supported the more general
> ns16550 device type."

Yes, that's a bit different from the wording on the elinux site. Thanks
for the pointer! Google was not my friend on this occasion, since I
managed to miss that site in my searches. Maybe it has gotten a higher
rank now that 0.2 is out, because now I find it easily?

>>> It's very common to use a compatible string that doesn't match exactly
>>> the specific hardware used. That's why it's called _compatible_ BTW.
>>
>> That's not how I read the above.
>>
> 
> That's not how I read it nor my experience with DT, but of course I
> may be wrong on this.

Either way, it should not be wrong to specify the more specific binding
before the generic fallback, as is done in the at91-tse850-3.dts
example I gave below.

>>> For example when a DTS define a UART node with an ns16550 compatible,
>>> they don't really mean that have a UART IC manufactured by National
>>> Semiconductor.
>>
>> That just tells me that most people are a little bit lazy and ready
>> to cut a corner or two when they can get away with it. Or that there
>> is some form of misunderstanding at work...
>>
> 
> For example, I usually see that different SoC families from the same
> vendor use the same compatible string for integrated peripherals just
> because are the same from a programming model point of view.
> 
> TI am33xx SoCs use a lot of omap3 compatible strings on their nodes
> and its similar on Exynos SoCs which are the two ARM SoCs I'm most
> familiar with. Following your logic that's wrong and instead a new
> compatible string should be added for the GPIO or pinctrl drivers even
> when are the same because refer to different devices.

Considering the above quote from the actual DT spec, I wouldn't say wrong.
But I'd still say that it should be preferred to list the actual device
before the fallback to some generic programming model compatible or some
previous version of the hardware/IP-block. Just in case an unintended
difference is discovered late in the game...

>>>> Sure, it happens to be compatible with "atmel,24c32", but that is
>>>> supposed to be written with a fallback as
>>>>
>>>>         "nxp,24c32", "atmel,24c32"
>>>
>>> This isn't a requirement really, systems integrators are free to use
>>> more than one <manufacturer,model> tuple in the compatible string if
>>> they want the DTB to be future proof, just in case there's a need for
>>> a more specific driver or if the programming model happened to not be
>>> the same at the end. This is usually done for the boards compatible
>>> string as an example, even when there isn't a struct machine_desc for
>>> the specific board compatible and only for the SoC family.
>>>
>>> So it's OK if you want to define the compatible as "nxp,24c32",
>>> "atmel,24c32", but that's a general OF concept and not something
>>> related to the at24 eeprom driver so I'm not sure if it should be
>>> mentioned in the at24 DT binding doc.
>>
>> One problem is that if "nxp,24c32" (or "nxp,24c02" as in the example
>> below) is not a valid compatible, the tooling will be correct to
>> complain about it. Currently, it is just a checkpatch deficiency that
>> it complains like this:
>>
>> $ scripts/checkpatch.pl -f arch/arm/boot/dts/at91-tse850-3.dts
>> WARNING: DT compatible string "nxp,24c02" appears un-documented -- check ./Documentation/devicetree/bindings/
>> #249: FILE: arch/arm/boot/dts/at91-tse850-3.dts:249:
>> +               compatible = "nxp,24c02", "atmel,24c02";
>>
> 
> But isn't that a bug in checkpatch? as long as there's a valid
> <manufacturer,model> tuple in the compatible string, it shouldn't
> complain.

Then there is a significant risk that speeling mistakes are not
caught. So, I don't think it will be considered a bug unless a DT
guru says so of course. I think the checkpatch intention is to catch
all undocumented compatibles. But I don't know of course...

>>>> if I understand correctly. So, why is that deprecated in this case?
>>>>
>>>> What if (a few years down the line) it is discovered that some weird
>>>> quirk is needed that is only appropriate for nxp chips?
>>>>
>>>> nxp is of course just an example, pick any manufacturer of eeproms
>>>> (supposedly) compatible with the atmel interface.
>>>>
>>>
>>> That's indeed a possibility and the reason why most DT nodes have a
>>> more specific <manufacturer,model> before the generic one matched by
>>> drivers. I really doubt that in the future it will be found that a
>>> more specific compatible string is needed for one manufacturer in this
>>> case, specially since the driver didn't even care about the
>>> manufacturers until recently.
>>
>> I'm not talking about the driver. But if what you say is true, that
>> change would have broken a number of existing DTBs. Is that really the
>> case?
>>
> 
> Sorry, I didn't get which change you meant.

I meant whatever change you implied with "the driver didn't even care
about the manufacturers until recently". However, on second reading it
may be the case that "care" did not imply that a breaking change was
made, that was however my interpretation. Oh well...

>>> So I think that makes no sense for a driver to support all possible
>>> manufacturers as possible compatible strings if all the devices have
>>> the same exact programming model.
>>
>> That's what the fallback is for. With that in place the driver can
>> start to care when there is a need but until then it can work just
>> as it always has. Without knowing the specific device, the driver has
>> less chance to adapt when the unexpected is discovered. But again,
>> I'm not really discussing driver details, I'm complaining about the
>> proposed changes to the bindings. I simply don't see how they make
>> sense.
>>
> 
> My point is that saying in a DT binding that you could have a more
> specific <manufacturer,model> followed by a generic one is redundant.
> That's already something one can do to make the DT future proof and
> latter if is found that the more specific pair is needed, then
> compatible can be added to the OF device ID table making the driver to
> match that an the <manufacturer,model> added to the DT binding making
> it formal.
> 
> That's my understanding at least, but I could be completely wrong too
> since I'm not a DT expert.

My understanding is that in order to do that future proofing, you first
have to document the more specific binding. Note that documenting the
more specific binding will not add any burden whatsoever to the driver,
as long as the fallback is in place, at least until a difference
between the specific and the generic device or programming model is
discovered... So, until you need to use the specific compatible, it is
pure documentation overhead.

This 1/5 patch deprecates the more specific bindings, and that seems to
be the wrong direction. *More* of the specific compatibles should be
encouraged (and documented) instead of less.

But what do I know? Anyway, I'll shut up now, I think I've made my point...

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 2/3] dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7
From: Tony Lindgren @ 2017-12-22 18:24 UTC (permalink / raw)
  To: Kishon Vijay Abraham I
  Cc: Rob Herring, Lorenzo Pieralisi, Bjorn Helgaas, Mark Rutland,
	linux-omap, devicetree, linux-pci, linux-kernel, nsekhar
In-Reply-To: <94336bfb-221d-95f7-72b2-09219b08099b@ti.com>

* Kishon Vijay Abraham I <kishon@ti.com> [171222 06:06]:
> Hi Rob,
> 
> On Thursday 21 December 2017 12:27 AM, Rob Herring wrote:
> > On Tue, Dec 19, 2017 at 02:28:22PM +0530, Kishon Vijay Abraham I wrote:
> >> Add syscon properties required for configuring PCIe in x2 lane mode.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> >> ---
> >>  Documentation/devicetree/bindings/pci/ti-pci.txt | 6 ++++++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> index 82cb875e4cec..bfbc77ac7355 100644
> >> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> @@ -13,6 +13,12 @@ PCIe DesignWare Controller
> >>   - ti,hwmods : Name of the hwmod associated to the pcie, "pcie<X>",
> >>  	       where <X> is the instance number of the pcie from the HW spec.
> >>   - num-lanes as specified in ../designware-pcie.txt
> >> + - ti,syscon-lane-conf : phandle/offset pair. Phandle to the system control
> >> +			 module and the register offset to specify 1 lane or
> >> +			 2 lane.
> >> + - ti,syscon-lane-sel : phandle/offset pair. Phandle to the system control
> >> +			module and the register offset to specify lane
> >> +			selection.
> > 
> > Adding a property for every syscon register doesn't really scale and 
> > doesn't work if the register layout changes.
> 
> The register layout doesn't really change between silicon revisions and for new
> SoCs, the phandle and the register offset for that SoC will have to be
> populated again.
> 
> Having said that, I'm not aware of any other alternative here.

Sorry I did not realize this is still open. Sounds like I need to
revert commit 4ece93c020e3 ("ARM: dts: dra7: Add properties to
enable PCIe x2 lane mode"), let me know if that is not the case.

Regards,

Tony

^ permalink raw reply

* Re: [PATCH v3 1/6] ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM
From: Fabio Estevam @ 2017-12-22 18:26 UTC (permalink / raw)
  To: Stefan Riedmueller
  Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Christian Hemp,
	Stefan Christ, Christoph Fritz
In-Reply-To: <1513940353-6145-2-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>

Hi Stefan,

I am sorry I missed some points during my last review.

On Fri, Dec 22, 2017 at 8:59 AM, Stefan Riedmueller
<s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> wrote:
> This patch adds basic support for PHYTEC phyCORE-i.MX 6 SOM with i.MX
> 6Quad/Dual or i.MX 6DualLight/Solo.
>
> Signed-off-by: Christian Hemp <c.hemp-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Stefan Christ <s.christ-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Christoph Fritz <chf.fritz-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Signed-off-by: Stefan Riedmueller <s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> ---
>  arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi | 282 ++++++++++++++++++++++
>  1 file changed, 282 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
>
> diff --git a/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
> new file mode 100644
> index 0000000..8501ac6
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
> @@ -0,0 +1,282 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2017 PHYTEC Messtechnik GmbH
> + * Author: Christian Hemp <c.hemp-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +       model = "PHYTEC phyCORE-i.MX 6";
> +       compatible = "phytec,imx6qdl-pcm058", "fsl,imx6qdl";

fsl,imx6qdl is not a documented compatible. Please remove the model
and compatible from the dtsi and put it only in the dts files.

> +
> +       aliases {
> +               rtc1 = &da9062_rtc;
> +               rtc2 = &snvs_rtc;
> +       };
> +
> +       /*
> +        * Set the minimum memory size here and
> +        * let the bootloader set the real size.
> +        */
> +       memory@10000000 {
> +               device_type = "memory";
> +               reg = <0x10000000 0x8000000>;
> +       };
> +
> +       gpio_leds_som: somleds {
> +               compatible = "gpio-leds";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_gpioleds_som>;
> +
> +               som_green {
> +                       label = "phycore:green";
> +                       gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
> +                       linux,default-trigger = "heartbeat";
> +               };
> +       };
> +};
> +
> +&ecspi1 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_ecspi1>;
> +       cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
> +       status = "okay";
> +
> +       flash: flash@0 {
> +               compatible = "m25p80";

Please check Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
for the proper usage of the SPI NOR compatible.

Or you can also check arch/arm/boot/dts/imx6qdl-sabresd.dtsi as reference.

With these two changes you can add:

Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 2/6] ARM: dts: imx6: Add initial support for phyBOARD-Mira
From: Fabio Estevam @ 2017-12-22 18:30 UTC (permalink / raw)
  To: Stefan Riedmueller
  Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Christian Hemp,
	Stefan Christ, Christoph Fritz
In-Reply-To: <1513940353-6145-3-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>

On Fri, Dec 22, 2017 at 8:59 AM, Stefan Riedmueller
<s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> wrote:
> This patch adds basic support for PHYTEC phyBOARD-Mira as carrier board
> for PHYTEC phyCORE-i.MX 6.
>
> Signed-off-by: Christian Hemp <c.hemp-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Stefan Christ <s.christ-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Christoph Fritz <chf.fritz-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Signed-off-by: Stefan Riedmueller <s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>

Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver
From: Philippe Ombredanne @ 2017-12-22 18:30 UTC (permalink / raw)
  To: Łukasz Stelmach
  Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
	Matt Mackall, Herbert Xu, Krzysztof Kozlowski, Kukjin Kim,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-crypto-u79uwXL29TY76Z2rM5mHXA,
	linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, LKML, Marek Szyprowski,
	Bartlomiej Zolnierkiewicz
In-Reply-To: <87y3luhg4f.fsf%l.stelmach-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

On Fri, Dec 22, 2017 at 5:38 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
> It was <2017-12-22 pią 14:34>, when Philippe Ombredanne wrote:
>> Łukasz,
>>
>> On Fri, Dec 22, 2017 at 2:23 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
>>> Add support for True Random Number Generator found in Samsung Exynos
>>> 5250+ SoCs.
>>>
>>> Signed-off-by: Łukasz Stelmach <l.stelmach-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>> Reviewed-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> <snip>
>>
>>> --- /dev/null
>>> +++ b/drivers/char/hw_random/exynos-trng.c
>>> @@ -0,0 +1,245 @@
>>> +/*
>>> + * RNG driver for Exynos TRNGs
>>> + *
>>> + * Author: Łukasz Stelmach <l.stelmach-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>> + *
>>> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
>>> + *
>>> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
>>> + * Krzysztof Kozłowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation;
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>
>>
>> Would you mind using the new SPDX tags documented in Thomas patch set
>> [1] rather than this fine but longer legalese?
>>
>> And if you could spread the word to others in your team this would be very nice.
>> See also this fine article posted by Mauro on the Samsung Open Source
>> Group Blog [2]
>> Thank you!
>
> Cool! We've been using SPDX to tag RPM packages in Tizen for three years or
> more. ;-)

Very nice! any pubic pointers?


>>> +MODULE_LICENSE("GPL");
>>
>> Per module.h this means GPL2 or later. This is not matching your
>> license above which does not state any version and therefore would
>> mean GPL1 or later,
>
> Thanks for spotting. My intention is GPL-2.0.
>
>> Please make sure you use something and common rather than this and
>> make sure your MODULE_LICENSE is consistent with the top level
>> license.
>>
>> Was it this way in the code from Krzysztof?
>
> Yes. And omap-rng, the second of my sources of reference, too. Actually,
> the majority of modules still specify "GPL".
>
>  281 | "Dual */*"
> 2082 | "GPL v2"
> 6359 | "GPL"
> ---- +---------
> 8784 | Total
>
> Fixing.


Sigh. That's a lot! Now I have the tool to spot all these differences.
I need to run this and review.
As a first pass aligning the MODULE_LICENSE with the top level would
be something that requires minimal discussion I guess.

>> [1] https://lkml.org/lkml/2017/12/4/934
>> [2] https://blogs.s-osg.org/linux-kernel-license-practices-revisited-spdx/
>
> --
> Łukasz Stelmach
> Samsung R&D Institute Poland
> Samsung Electronics

-- 
Cordially
Philippe Ombredanne
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 3/6] ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6Quad/Dual RDK
From: Fabio Estevam @ 2017-12-22 18:31 UTC (permalink / raw)
  To: Stefan Riedmueller
  Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Christian Hemp,
	Stefan Christ
In-Reply-To: <1513940353-6145-4-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>

On Fri, Dec 22, 2017 at 8:59 AM, Stefan Riedmueller
<s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> wrote:
> From: Christian Hemp <c.hemp-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
>
> Add support for the PHYTEC phyBOARD-Mira Rapid Development Kit with
> i.MX 6Quad/Dual with eMMC or NAND.
>
> Following interfaces are supported:
> - Gigabit Ethernet
> - USB Host
> - CAN
> - RS232
> - PCIe
> - LVDS
> - HDMI
>
> Signed-off-by: Christian Hemp <c.hemp-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Stefan Christ <s.christ-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Stefan Riedmueller <s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>

Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v5] hwrng: exynos - add Samsung Exynos True RNG driver
From: Philippe Ombredanne @ 2017-12-22 18:31 UTC (permalink / raw)
  To: Łukasz Stelmach
  Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
	Matt Mackall, Herbert Xu, Krzysztof Kozlowski, Kukjin Kim,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-crypto, linux-samsung-soc, LKML, Marek Szyprowski,
	Bartlomiej Zolnierkiewicz
In-Reply-To: <20171222164835.1051-1-l.stelmach@samsung.com>

Łukasz,

On Fri, Dec 22, 2017 at 5:48 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
> Add support for True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> Changes since v4:
>
> - SPDX license header instead of the traditional blurb.
>
> - MODULE_LICENSE("GPL v2") instead of "GPL"
>
> Thank you, Philippe Ombredanne.

You have my cheerful ack for these changes:

Acked-by: Philippe Ombredanne <pombredanne@nexb.com>

-- 
Cordially
Philippe Ombredanne

^ permalink raw reply

* Re: [PATCH v3 5/6] ARM: dts: imx6: Add support for phyBOARD-Mira with i.MX 6QuadPlus
From: Fabio Estevam @ 2017-12-22 18:32 UTC (permalink / raw)
  To: Stefan Riedmueller
  Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Enrico Scholz,
	Stefan Lengfeld, Christian Hemp
In-Reply-To: <1513940353-6145-6-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>

On Fri, Dec 22, 2017 at 8:59 AM, Stefan Riedmueller
<s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> wrote:
> From: Enrico Scholz <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org>
>
> Add support for the PHYTEC phyBOARD-Mira with i.MX 6QuadPlus with NAND.
> It is based on the phyBOARD-Mira with i.MX 6Quad/Dual and supports the
> same interfaces.
>
> Signed-off-by: Enrico Scholz <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org>
> Signed-off-by: Stefan Lengfeld <s.lengfeld-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Christian Hemp <c.hemp-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Stefan Riedmueller <s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>

Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v4 2/4] ARM: dts: imx53: add srtc node
From: Fabio Estevam @ 2017-12-22 18:36 UTC (permalink / raw)
  To: linux-kernel-dev
  Cc: Mark Rutland, Alessandro Zummo, Patrick Bruenn,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list, Russell King, Noel Vellemans, Rob Herring,
	Alexandre Belloni, Sascha Hauer, Philippe Ombredanne,
	Fabio Estevam, Lothar Waßmann, Shawn Guo,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20171218115133.16371-3-linux-kernel-dev@beckhoff.com>

On Mon, Dec 18, 2017 at 9:51 AM,  <linux-kernel-dev@beckhoff.com> wrote:
> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>
> rtc-mxc_v2 driver will add support for the i.MX53 SRTC
>
> Note: we keep the 'srtc' label to avoid duplicate with imx53-m53.dtsi
>
> Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>

Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>

^ permalink raw reply

* Re: [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Robert Jarzmik @ 2017-12-22 20:11 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel RAYNAL, David Woodhouse, Brian Norris, Marek Vasut,
	Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Russell King, Daniel Mack, Haojian Zhuang, Eric Miao,
	Catalin Marinas, Will Deacon, Ezequiel Garcia <ezequi>
In-Reply-To: <20171220224121.2cb6f690@bbrezillon>

Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:

> Looks like there is a mismatch on the nand bus width detected by the
> core and the one declared by the driver. Can you try with the following
> diff applied?

Sure.

Now I get a lot of these message which I didn't have before :
[   26.897372] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 126976 bytes from PEB 242:4096, read only 126976 bytes, retry
[   26.928559] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 126976 bytes from PEB 242:4096, read only 126976 bytes, retry
[   26.959623] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 126976 bytes from PEB 242:4096, read only 126976 bytes, retry
[   26.990714] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 126976 bytes from PEB 242:4096, read 126976 bytes
[   27.002084] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc1-00041-ge371e97 #737
[   27.009674] Hardware name: PXA3xx Platform Development Kit (aka Zylonite)
[   27.016750] [<c0010440>] (unwind_backtrace) from [<c000df94>] (show_stack+0x10/0x14)
[   27.024729] [<c000df94>] (show_stack) from [<c02c5bd4>] (ubi_io_read+0x124/0x368)
[   27.032453] [<c02c5bd4>] (ubi_io_read) from [<c02cd550>] (ubi_attach+0xbd8/0x1868)
[   27.040148] [<c02cd550>] (ubi_attach) from [<c02be7c4>] (ubi_attach_mtd_dev+0x548/0xe58)
[   27.048473] [<c02be7c4>] (ubi_attach_mtd_dev) from [<c05526e4>] (ubi_init+0x134/0x1d4)
[   27.056623] [<c05526e4>] (ubi_init) from [<c00099f8>] (do_one_initcall+0x3c/0x17c)
[   27.064466] [<c00099f8>] (do_one_initcall) from [<c053fd80>] (kernel_init_freeable+0x104/0x1c0)
[   27.073398] [<c053fd80>] (kernel_init_freeable) from [<c0423ab8>] (kernel_init+0x8/0xf8)
[   27.081715] [<c0423ab8>] (kernel_init) from [<c000a780>] (ret_from_fork+0x14/0x34)
[   27.090115] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 243:2048, read only 64 bytes, retry
[   27.102363] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 243:2048, read only 64 bytes, retry
[   27.114586] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 243:2048, read only 64 bytes, retry
[   27.126813] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 243:2048, read 64 bytes
[   27.137416] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc1-00041-ge371e97 #737
[   27.145143] Hardware name: PXA3xx Platform Development Kit (aka Zylonite)
[   27.152207] [<c0010440>] (unwind_backtrace) from [<c000df94>] (show_stack+0x10/0x14)
[   27.160037] [<c000df94>] (show_stack) from [<c02c5bd4>] (ubi_io_read+0x124/0x368)
[   27.167742] [<c02c5bd4>] (ubi_io_read) from [<c02c63dc>] (ubi_io_read_vid_hdr+0x60/0x3ac)
[   27.176156] [<c02c63dc>] (ubi_io_read_vid_hdr) from [<c02cce58>] (ubi_attach+0x4e0/0x1868)
[   27.184675] [<c02cce58>] (ubi_attach) from [<c02be7c4>] (ubi_attach_mtd_dev+0x548/0xe58)
[   27.193010] [<c02be7c4>] (ubi_attach_mtd_dev) from [<c05526e4>] (ubi_init+0x134/0x1d4)
[   27.201159] [<c05526e4>] (ubi_init) from [<c00099f8>] (do_one_initcall+0x3c/0x17c)
[   27.208839] [<c00099f8>] (do_one_initcall) from [<c053fd80>] (kernel_init_freeable+0x104/0x1c0)
[   27.217755] [<c053fd80>] (kernel_init_freeable) from [<c0423ab8>] (kernel_init+0x8/0xf8)
[   27.226074] [<c0423ab8>] (kernel_init) from [<c000a780>] (ret_from_fork+0x14/0x34)

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 3/5] mtd: nand: replace pxa3xx_nand driver by its rework called marvell_nand
From: Robert Jarzmik @ 2017-12-22 20:47 UTC (permalink / raw)
  To: Miquel Raynal, David Woodhouse, Brian Norris, Boris Brezillon
  Cc: Marek Vasut, Richard Weinberger, Cyrille Pitchen, Rob Herring,
	Mark Rutland, Jason Cooper, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, Russell King, Daniel Mack, Haojian Zhuang,
	Eric Miao, Catalin Marinas, Will Deacon, Ezequiel Garcia,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thoma
In-Reply-To: <20171219132942.27433-4-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:

> Actually remove pxa3xx_nand.c to let marvell_nand.c be compiled instead.
> Also change the defconfig files using it as well as some board files
> depending on CONFIG_MTD_NAND_PXA3xx.
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Actually that approach doesn't quite suit me.
I'm not convinced at all a new rewrite of the driver will be stable right out of
the box as the old one is.

What I would propose instead is :
 - keep both the new marvell nand driver and the old pxa3xx_nand driver
 - switch pxa_defconfig to compile them both
 - continue testing (with my help)

Once I see the marvell_nand is working properly, we can remove pca3xx_nand in a
second stage, keeping the pxa platform functional all along.

Would you agree to that path ?

As a side not, this patch should be split into 2 parts :
 - one for arch/arm -> switch to the new driver
 - one for drivers/mtd -> removal of the old driver

Cheers.

--
Robert
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH 1/2] ARM: dts: sunxi: Switch MMC nodes away from cd-inverted property
From: Tuomas Tynkkynen @ 2017-12-22 20:57 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai
  Cc: Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Tuomas Tynkkynen

Using the cd-inverted property is not useful when GPIOs are used as card
detects since the polarity can be specified with the usual
GPIO_ACTIVE_(HIGH|LOW) GPIO flags. It has also caused confusion for
U-Boot developers, so migrate all sunxi boards away from cd-inverted.

Signed-off-by: Tuomas Tynkkynen <tuomas-yrGDUoBaLx3QT0dZR+AlfA@public.gmane.org>
---
Tested on Pcduino3 Nano.

 arch/arm/boot/dts/sun4i-a10-a1000.dts                    | 3 +--
 arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts               | 3 +--
 arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts          | 3 +--
 arch/arm/boot/dts/sun4i-a10-cubieboard.dts               | 3 +--
 arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts         | 3 +--
 arch/arm/boot/dts/sun4i-a10-gemei-g9.dts                 | 3 +--
 arch/arm/boot/dts/sun4i-a10-hackberry.dts                | 3 +--
 arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts             | 3 +--
 arch/arm/boot/dts/sun4i-a10-inet1.dts                    | 3 +--
 arch/arm/boot/dts/sun4i-a10-inet97fv2.dts                | 3 +--
 arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts             | 3 +--
 arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts     | 3 +--
 arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts               | 3 +--
 arch/arm/boot/dts/sun4i-a10-marsboard.dts                | 3 +--
 arch/arm/boot/dts/sun4i-a10-mini-xplus.dts               | 3 +--
 arch/arm/boot/dts/sun4i-a10-mk802.dts                    | 3 +--
 arch/arm/boot/dts/sun4i-a10-mk802ii.dts                  | 3 +--
 arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts           | 3 +--
 arch/arm/boot/dts/sun4i-a10-pcduino.dts                  | 3 +--
 arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts         | 3 +--
 arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts             | 3 +--
 arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts             | 3 +--
 arch/arm/boot/dts/sun5i-a10s-mk802.dts                   | 3 +--
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts         | 6 ++----
 arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts            | 3 +--
 arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts                 | 3 +--
 arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts   | 3 +--
 arch/arm/boot/dts/sun5i-a13-hsg-h702.dts                 | 3 +--
 arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts          | 3 +--
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts                | 3 +--
 arch/arm/boot/dts/sun5i-gr8-evb.dts                      | 3 +--
 arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi     | 3 +--
 arch/arm/boot/dts/sun6i-a31-colombus.dts                 | 3 +--
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts              | 3 +--
 arch/arm/boot/dts/sun6i-a31-i7.dts                       | 3 +--
 arch/arm/boot/dts/sun6i-a31-m9.dts                       | 3 +--
 arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts         | 3 +--
 arch/arm/boot/dts/sun6i-a31s-primo81.dts                 | 3 +--
 arch/arm/boot/dts/sun6i-a31s-sina31s.dts                 | 3 +--
 arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts         | 3 +--
 arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts | 3 +--
 arch/arm/boot/dts/sun6i-reference-design-tablet.dtsi     | 3 +--
 arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts         | 3 +--
 arch/arm/boot/dts/sun7i-a20-bananapi.dts                 | 3 +--
 arch/arm/boot/dts/sun7i-a20-bananapro.dts                | 3 +--
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts              | 3 +--
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts               | 3 +--
 arch/arm/boot/dts/sun7i-a20-hummingbird.dts              | 3 +--
 arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts                | 3 +--
 arch/arm/boot/dts/sun7i-a20-icnova-swac.dts              | 3 +--
 arch/arm/boot/dts/sun7i-a20-itead-ibox.dts               | 3 +--
 arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts                | 3 +--
 arch/arm/boot/dts/sun7i-a20-m3.dts                       | 3 +--
 arch/arm/boot/dts/sun7i-a20-mk808c.dts                   | 3 +--
 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts           | 6 ++----
 arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts           | 3 +--
 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts          | 3 +--
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts          | 6 ++----
 arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts            | 6 ++----
 arch/arm/boot/dts/sun7i-a20-orangepi.dts                 | 3 +--
 arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts            | 3 +--
 arch/arm/boot/dts/sun7i-a20-pcduino3.dts                 | 3 +--
 arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts           | 3 +--
 arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts         | 3 +--
 arch/arm/boot/dts/sun8i-a23-evb.dts                      | 3 +--
 arch/arm/boot/dts/sun8i-a33-olinuxino.dts                | 3 +--
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts           | 3 +--
 arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts   | 3 +--
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts             | 3 +--
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts         | 3 +--
 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts        | 3 +--
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts          | 3 +--
 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts                | 3 +--
 arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts       | 3 +--
 arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts            | 3 +--
 arch/arm/boot/dts/sun8i-h3-nanopi.dtsi                   | 3 +--
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts                | 3 +--
 arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts             | 3 +--
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts              | 3 +--
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts               | 3 +--
 arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts             | 3 +--
 arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts        | 3 +--
 arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi     | 3 +--
 arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts        | 3 +--
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts              | 3 +--
 arch/arm/boot/dts/sun9i-a80-optimus.dts                  | 3 +--
 86 files changed, 90 insertions(+), 180 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/sun4i-a10-a1000.dts
index 09e909576c61..6c254ec4c85b 100644
--- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
+++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
@@ -164,8 +164,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts b/arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts
index 39ba4ccb9e2e..38a2c4134952 100644
--- a/arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts
+++ b/arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts
@@ -106,8 +106,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
index dfc88aee4fe3..cf7b392dff31 100644
--- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
+++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
@@ -123,8 +123,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index 1982c8c238c5..197a1f2b75ff 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -162,8 +162,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts b/arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts
index 147cbc5e08ac..896e27a08727 100644
--- a/arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts
+++ b/arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts
@@ -150,8 +150,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
index 41ca8bded89f..ea7a59dcf8f9 100644
--- a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
+++ b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
@@ -141,8 +141,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH01 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH01 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-hackberry.dts b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
index f33e42d6ce8b..cc988ccd5ca7 100644
--- a/arch/arm/boot/dts/sun4i-a10-hackberry.dts
+++ b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
@@ -106,8 +106,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
index 35c57d065dd8..f63767cddd8e 100644
--- a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
+++ b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
@@ -78,8 +78,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-inet1.dts b/arch/arm/boot/dts/sun4i-a10-inet1.dts
index 9482e831a9a1..26d0c1d6a02b 100644
--- a/arch/arm/boot/dts/sun4i-a10-inet1.dts
+++ b/arch/arm/boot/dts/sun4i-a10-inet1.dts
@@ -152,8 +152,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
index 4b5c91c8e85b..5d096528e75a 100644
--- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
+++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
@@ -142,8 +142,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
index 13224f5ac166..221acd10f6c8 100644
--- a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
+++ b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
@@ -300,8 +300,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts b/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
index d22bd79562d8..80ecd78247ac 100644
--- a/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
+++ b/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
@@ -106,8 +106,7 @@
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts b/arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts
index 879141ca6027..247fa27ef717 100644
--- a/arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts
+++ b/arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts
@@ -133,8 +133,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-marsboard.dts b/arch/arm/boot/dts/sun4i-a10-marsboard.dts
index 435c551aef0f..0dbf69576512 100644
--- a/arch/arm/boot/dts/sun4i-a10-marsboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-marsboard.dts
@@ -132,8 +132,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts b/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
index 1b639e5f9172..f9d74e21031d 100644
--- a/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
+++ b/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
@@ -96,8 +96,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-mk802.dts b/arch/arm/boot/dts/sun4i-a10-mk802.dts
index 7198b34e2e50..face1925ee5b 100644
--- a/arch/arm/boot/dts/sun4i-a10-mk802.dts
+++ b/arch/arm/boot/dts/sun4i-a10-mk802.dts
@@ -73,8 +73,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-mk802ii.dts b/arch/arm/boot/dts/sun4i-a10-mk802ii.dts
index e460da2eb139..17dcdf031118 100644
--- a/arch/arm/boot/dts/sun4i-a10-mk802ii.dts
+++ b/arch/arm/boot/dts/sun4i-a10-mk802ii.dts
@@ -82,8 +82,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
index 49247fbe6acd..f15f01955fdf 100644
--- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
@@ -165,8 +165,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino.dts b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
index 6e140547b638..b97a0f2f20b9 100644
--- a/arch/arm/boot/dts/sun4i-a10-pcduino.dts
+++ b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
@@ -140,8 +140,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts b/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
index 5081303f79e7..84b25be1ac94 100644
--- a/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
+++ b/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
@@ -138,8 +138,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts b/arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts
index d2dee8d434bf..39504d720efc 100644
--- a/arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts
@@ -93,8 +93,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_t003>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
-	cd-inverted;
+	cd-gpios = <&pio 6 1 GPIO_ACTIVE_LOW>; /* PG1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
index 16f839df4227..8d4fb9331212 100644
--- a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
@@ -104,8 +104,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_t004>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
-	cd-inverted;
+	cd-gpios = <&pio 6 1 GPIO_ACTIVE_LOW>; /* PG1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a10s-mk802.dts b/arch/arm/boot/dts/sun5i-a10s-mk802.dts
index 020aa9d6c31d..dd7fd5c3d76f 100644
--- a/arch/arm/boot/dts/sun5i-a10s-mk802.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-mk802.dts
@@ -92,8 +92,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_mk802>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
-	cd-inverted;
+	cd-gpios = <&pio 6 1 GPIO_ACTIVE_LOW>; /* PG1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index da95118af4dc..2c902ed2c87a 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -201,8 +201,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_olinuxino_micro>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
-	cd-inverted;
+	cd-gpios = <&pio 6 1 GPIO_ACTIVE_LOW>; /* PG1 */
 	status = "okay";
 };
 
@@ -211,8 +210,7 @@
 	pinctrl-0 = <&mmc1_pins_a>, <&mmc1_cd_pin_olinuxino_micro>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 13 GPIO_ACTIVE_HIGH>; /* PG13 */
-	cd-inverted;
+	cd-gpios = <&pio 6 13 GPIO_ACTIVE_LOW>; /* PG13 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts b/arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts
index 262b3669f04d..034853d1c08f 100644
--- a/arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts
@@ -80,8 +80,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_r7>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
-	cd-inverted;
+	cd-gpios = <&pio 6 1 GPIO_ACTIVE_LOW>; /* PG1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts b/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
index 5482be174e12..3f68ef5d92a0 100644
--- a/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
@@ -130,8 +130,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_wobo_i5>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
-	cd-inverted;
+	cd-gpios = <&pio 1 3 GPIO_ACTIVE_LOW>; /* PB3 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
index 3dbb0d7c2f8c..378214d8316e 100644
--- a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
+++ b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
@@ -125,8 +125,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_d709>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 0 GPIO_ACTIVE_HIGH>; /* PG0 */
-	cd-inverted;
+	cd-gpios = <&pio 6 0 GPIO_ACTIVE_LOW>; /* PG0 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts b/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
index 584fa579ded2..7ee0c3f6d7a1 100644
--- a/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
+++ b/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
@@ -120,8 +120,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_h702>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 0 GPIO_ACTIVE_HIGH>; /* PG0 */
-	cd-inverted;
+	cd-gpios = <&pio 6 0 GPIO_ACTIVE_LOW>; /* PG0 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts b/arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts
index 3a831eaf1dfc..aa4b34fd9126 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts
@@ -99,8 +99,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_olinuxinom>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 0 GPIO_ACTIVE_HIGH>; /* PG0 */
-	cd-inverted;
+	cd-gpios = <&pio 6 0 GPIO_ACTIVE_LOW>; /* PG0 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index 4b9af423c6d5..437ad913a373 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -194,8 +194,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_olinuxino>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 0 GPIO_ACTIVE_HIGH>; /* PG0 */
-	cd-inverted;
+	cd-gpios = <&pio 6 0 GPIO_ACTIVE_LOW>; /* PG0 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-gr8-evb.dts b/arch/arm/boot/dts/sun5i-gr8-evb.dts
index 558c16a30543..5f0adc0f7bb4 100644
--- a/arch/arm/boot/dts/sun5i-gr8-evb.dts
+++ b/arch/arm/boot/dts/sun5i-gr8-evb.dts
@@ -236,8 +236,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_gr8_evb>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 0 GPIO_ACTIVE_HIGH>; /* PG0 */
-	cd-inverted;
+	cd-gpios = <&pio 6 0 GPIO_ACTIVE_LOW>; /* PG0 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
index 49229b3d5492..8acbaab14fe5 100644
--- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
@@ -127,8 +127,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	vmmc-supply = <&reg_vcc3v0>;
 	bus-width = <4>;
-	cd-gpios = <&pio 6 0 GPIO_ACTIVE_HIGH>; /* PG0 */
-	cd-inverted;
+	cd-gpios = <&pio 6 0 GPIO_ACTIVE_LOW>; /* PG0 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31-colombus.dts b/arch/arm/boot/dts/sun6i-a31-colombus.dts
index 85eff0307ca4..939c497a6f70 100644
--- a/arch/arm/boot/dts/sun6i-a31-colombus.dts
+++ b/arch/arm/boot/dts/sun6i-a31-colombus.dts
@@ -117,8 +117,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_colombus>;
 	vmmc-supply = <&reg_vcc3v0>;
 	bus-width = <4>;
-	cd-gpios = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
-	cd-inverted;
+	cd-gpios = <&pio 0 8 GPIO_ACTIVE_LOW>; /* PA8 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 19e382a11297..ce4f9e9834bf 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -218,8 +218,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_hummingbird>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
-	cd-inverted;
+	cd-gpios = <&pio 0 8 GPIO_ACTIVE_LOW>; /* PA8 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31-i7.dts b/arch/arm/boot/dts/sun6i-a31-i7.dts
index 010a84c7c012..2e0a672c8031 100644
--- a/arch/arm/boot/dts/sun6i-a31-i7.dts
+++ b/arch/arm/boot/dts/sun6i-a31-i7.dts
@@ -124,8 +124,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_i7>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
-	cd-inverted;
+	cd-gpios = <&pio 7 22 GPIO_ACTIVE_LOW>; /* PH22 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31-m9.dts b/arch/arm/boot/dts/sun6i-a31-m9.dts
index 50605fd4449e..9698f6d38d03 100644
--- a/arch/arm/boot/dts/sun6i-a31-m9.dts
+++ b/arch/arm/boot/dts/sun6i-a31-m9.dts
@@ -107,8 +107,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_m9>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
-	cd-inverted;
+	cd-gpios = <&pio 7 22 GPIO_ACTIVE_LOW>; /* PH22 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts b/arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts
index 5219556e9f73..bb14b171b160 100644
--- a/arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts
+++ b/arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts
@@ -107,8 +107,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_m9>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
-	cd-inverted;
+	cd-gpios = <&pio 7 22 GPIO_ACTIVE_LOW>; /* PH22 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
index 0cdb38ab3377..4cb9664cdb29 100644
--- a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -151,8 +151,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_primo81>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
-	cd-inverted;
+	cd-gpios = <&pio 0 8 GPIO_ACTIVE_LOW>; /* PA8 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
index 298476485bb4..da0ccf5a2c44 100644
--- a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
@@ -167,8 +167,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_sina31s>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 0 4 GPIO_ACTIVE_HIGH>; /* PA4 */
-	cd-inverted;
+	cd-gpios = <&pio 0 4 GPIO_ACTIVE_LOW>; /* PA4 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
index 51e6f1d21c32..3077e8ec9cd9 100644
--- a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
@@ -120,8 +120,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_bpi_m2>;
 	vmmc-supply = <&reg_vcc3v0>;
 	bus-width = <4>;
-	cd-gpios = <&pio 0 4 GPIO_ACTIVE_HIGH>; /* PA4 */
-	cd-inverted;
+	cd-gpios = <&pio 0 4 GPIO_ACTIVE_LOW>; /* PA4 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts b/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
index f3edf9ca435c..aab6c1720ef7 100644
--- a/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
@@ -102,8 +102,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_bs1078v2>;
 	vmmc-supply = <&reg_vcc3v0>;
 	bus-width = <4>;
-	cd-gpios = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
-	cd-inverted;
+	cd-gpios = <&pio 0 8 GPIO_ACTIVE_LOW>; /* PA8 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun6i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun6i-reference-design-tablet.dtsi
index 3cc4046b904a..4e72e4f3ef96 100644
--- a/arch/arm/boot/dts/sun6i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun6i-reference-design-tablet.dtsi
@@ -69,8 +69,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_e708_q1>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
-	cd-inverted;
+	cd-gpios = <&pio 0 8 GPIO_ACTIVE_LOW>; /* PA8 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index 4ed3162e3e5a..763cb03033c4 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -184,8 +184,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_bpi_m1p>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
-	cd-inverted;
+	cd-gpios = <&pio 7 10 GPIO_ACTIVE_LOW>; /* PH10 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 88a1c2363c6c..6f744f8931f0 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -159,8 +159,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_bananapi>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
-	cd-inverted;
+	cd-gpios = <&pio 7 10 GPIO_ACTIVE_LOW>; /* PH10 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index e7af1b7c33d5..0898eb6162f5 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -158,8 +158,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_bananapro>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
-	cd-inverted;
+	cd-gpios = <&pio 7 10 GPIO_ACTIVE_LOW>; /* PH10 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index 39f43e4eb742..942ac9dfd4a5 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -165,8 +165,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 8c9bedc602ec..5649161de1d7 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -206,8 +206,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-hummingbird.dts b/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
index 6e6264cd69f8..1f0e5ecbf0c4 100644
--- a/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
+++ b/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
@@ -163,8 +163,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v0>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
index 55809973a568..2e3f2f29d124 100644
--- a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
+++ b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
@@ -160,8 +160,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts b/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
index 794e7617f545..926fa194eb1b 100644
--- a/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
+++ b/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
@@ -107,8 +107,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 8 5 GPIO_ACTIVE_HIGH>; /* PI5 */
-	cd-inverted;
+	cd-gpios = <&pio 8 5 GPIO_ACTIVE_LOW>; /* PI5 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
index 8a8a6dbcd414..1b05ba466e7d 100644
--- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
+++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
@@ -124,8 +124,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
index 442f3c755f36..b1ab7c1c33e3 100644
--- a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
+++ b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
@@ -227,8 +227,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_lamobo_r1>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
-	cd-inverted;
+	cd-gpios = <&pio 7 10 GPIO_ACTIVE_LOW>; /* PH10 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-m3.dts b/arch/arm/boot/dts/sun7i-a20-m3.dts
index 43c94787ef07..e91a209850bc 100644
--- a/arch/arm/boot/dts/sun7i-a20-m3.dts
+++ b/arch/arm/boot/dts/sun7i-a20-m3.dts
@@ -120,8 +120,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-mk808c.dts b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
index f7413094183c..ce3f09aaeed2 100644
--- a/arch/arm/boot/dts/sun7i-a20-mk808c.dts
+++ b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
@@ -112,8 +112,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v0>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
index 64c8ef9a2756..8f34731dee34 100644
--- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
@@ -190,8 +190,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
@@ -200,8 +199,7 @@
 	pinctrl-0 = <&mmc3_pins_a>, <&mmc3_cd_pin_olimex_som_evb>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 0 GPIO_ACTIVE_HIGH>; /* PH0 */
-	cd-inverted;
+	cd-gpios = <&pio 7 0 GPIO_ACTIVE_LOW>; /* PH0 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
index edf9c3c6c0d7..d20fd03596e9 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
@@ -158,8 +158,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index ba250189d07f..b828677f331d 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -159,8 +159,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index dffbaa24b3ee..866d230593be 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -226,8 +226,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
@@ -236,8 +235,7 @@
 	pinctrl-0 = <&mmc3_pins_a>, <&mmc3_cd_pin_olinuxinom>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
-	cd-inverted;
+	cd-gpios = <&pio 7 11 GPIO_ACTIVE_LOW>; /* PH11 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts b/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
index 7af4c8fc1865..a5ae0c55bf5b 100644
--- a/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
+++ b/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
@@ -144,8 +144,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_orangepi>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
-	cd-inverted;
+	cd-gpios = <&pio 7 10 GPIO_ACTIVE_LOW>; /* PH10 */
 	status = "okay";
 };
 
@@ -154,8 +153,7 @@
 	pinctrl-0 = <&mmc3_pins_a>, <&mmc3_cd_pin_orangepi>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
-	cd-inverted;
+	cd-gpios = <&pio 7 11 GPIO_ACTIVE_LOW>; /* PH11 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi.dts b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
index 0a8d4a05e8a0..7a4244e57589 100644
--- a/arch/arm/boot/dts/sun7i-a20-orangepi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
@@ -135,8 +135,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_orangepi>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
-	cd-inverted;
+	cd-gpios = <&pio 7 10 GPIO_ACTIVE_LOW>; /* PH10 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
index fb591f32252c..bfca960b03e0 100644
--- a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
+++ b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
@@ -158,8 +158,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
index 777152a3df0f..c576f101fbde 100644
--- a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
+++ b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
@@ -159,8 +159,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
index f8d0aafb9f88..8202c87ca6a3 100644
--- a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
+++ b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
@@ -154,8 +154,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
index 7f8405a0dd0f..ff5c1086585c 100644
--- a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
+++ b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
@@ -123,8 +123,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
-	cd-inverted;
+	cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-a23-evb.dts b/arch/arm/boot/dts/sun8i-a23-evb.dts
index 87289a60c520..8a93697df3a5 100644
--- a/arch/arm/boot/dts/sun8i-a23-evb.dts
+++ b/arch/arm/boot/dts/sun8i-a23-evb.dts
@@ -107,8 +107,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_evb>;
 	vmmc-supply = <&reg_vcc3v0>;
 	bus-width = <4>;
-	cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
-	cd-inverted;
+	cd-gpios = <&pio 1 4 GPIO_ACTIVE_LOW>; /* PB4 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
index be9a6b8d7a1e..9757265c58d4 100644
--- a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
+++ b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
@@ -81,8 +81,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_olinuxino>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
-	cd-inverted;
+	cd-gpios = <&pio 1 4 GPIO_ACTIVE_LOW>; /* PB4 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 433cf2a2a9a2..541acb4d2b91 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -144,8 +144,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_sina33>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
-	cd-inverted;
+	cd-gpios = <&pio 1 4 GPIO_ACTIVE_LOW>; /* PB4 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
index 5091cecbcd1e..36ecebaff3c0 100644
--- a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
@@ -87,9 +87,8 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	bus-width = <4>;
-	cd-inverted;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..1890d41b7fae 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -112,8 +112,7 @@
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
index 6da08cd0e107..88decb0747ac 100644
--- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
@@ -176,8 +176,7 @@
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index 6713d0f2b3f4..9a5017bb1440 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -116,8 +116,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index f1c3f1cc4d97..3a196a86a984 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -140,8 +140,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
index 10da56e86ab8..7824f0dbf022 100644
--- a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
@@ -119,8 +119,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
index d406571a0dd6..d9dc14fe2aa3 100644
--- a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
@@ -154,8 +154,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_vcc_io>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
index 03ff6f8b93ff..52eb3287c192 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
@@ -79,8 +79,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi b/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi
index 7646e331bd29..e9af61394f5d 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi
@@ -95,8 +95,7 @@
 
 &mmc0 {
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index b20be95b49d5..629f76b85005 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -136,8 +136,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts
index a70a1daf4e2c..398f975b380d 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts
@@ -110,8 +110,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 82e5d28cd698..40941fef4ff3 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -110,8 +110,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index d22546df1b82..c4769def8cd6 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -132,8 +132,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	vmmc-supply = <&reg_vcc3v3>;
 	bus-width = <4>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
index eaf09666720d..0dbdb29a8fff 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
@@ -150,8 +150,7 @@
 	pinctrl-0 = <&mmc0_pins_a>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
-	cd-inverted;
+	cd-gpios = <&pio 1 4 GPIO_ACTIVE_LOW>; /* PB4 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 8c5efe2a9881..27d9ccd0ef2f 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -164,8 +164,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>; /* PH13 */
-	cd-inverted;
+	cd-gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
index d6bd15898db6..f51f37cc721d 100644
--- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
@@ -85,8 +85,7 @@
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
-	cd-inverted;
+	cd-gpios = <&pio 1 4 GPIO_ACTIVE_LOW>; /* PB4 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
index fe16fc0eb518..a26d72c3f9b5 100644
--- a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
+++ b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
@@ -150,8 +150,7 @@
 &mmc0 {
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>; /* PH13 */
-	cd-inverted;
+	cd-gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 4024639aa005..31b06ecbc306 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -88,8 +88,7 @@
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */
-	cd-inverted;
+	cd-gpios = <&pio 7 18 GPIO_ACTIVE_LOW>; /* PH18 */
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index a9b807be99a0..58a199b0e494 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -125,8 +125,7 @@
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
-	cd-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH8 */
-	cd-inverted;
+	cd-gpios = <&pio 7 18 GPIO_ACTIVE_LOW>; /* PH8 */
 	status = "okay";
 };
 
-- 
2.15.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* [PATCH 2/2] arm64: dts: sunxi: Switch MMC nodes away from cd-inverted property
From: Tuomas Tynkkynen @ 2017-12-22 20:57 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai
  Cc: Rob Herring, Mark Rutland, devicetree, linux-arm-kernel,
	linux-kernel, Tuomas Tynkkynen
In-Reply-To: <20171222205738.2389-1-tuomas@tuxera.com>

Using the cd-inverted property is not useful when GPIOs are used as card
detects since the polarity can be specified with the usual
GPIO_ACTIVE_(HIGH|LOW) GPIO flags. It has also caused confusion for
U-Boot developers, so migrate all sunxi boards away from cd-inverted.

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
---
Compile-tested.

 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 3 +--
 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 3 +--
 arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts    | 3 +--
 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 3 +--
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts       | 3 +--
 5 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index a6975670cd1c..2250dec9974c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -120,8 +120,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
 	disable-wp;
 	bus-width = <4>;
 	status = "okay";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index 2beef9e6cb88..e2dce48fa29a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -82,8 +82,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
 	disable-wp;
 	bus-width = <4>;
 	status = "okay";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index 8807664f363a..3b3081b10ecb 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -68,8 +68,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
 	disable-wp;
 	bus-width = <4>;
 	status = "okay";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
index 240d35731d10..bf42690a3361 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
@@ -67,8 +67,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
 	status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 604cdaedac38..3e9e7374e7eb 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -103,8 +103,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>;
 	vmmc-supply = <&reg_dcdc1>;
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
-	cd-inverted;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
 	disable-wp;
 	bus-width = <4>;
 	status = "okay";
-- 
2.15.0

^ permalink raw reply related

* Re: [PATCH v2 3/5] mtd: nand: replace pxa3xx_nand driver by its rework called marvell_nand
From: Boris Brezillon @ 2017-12-22 21:10 UTC (permalink / raw)
  To: Robert Jarzmik
  Cc: Miquel Raynal, David Woodhouse, Brian Norris, Marek Vasut,
	Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Russell King, Daniel Mack, Haojian Zhuang, Eric Miao,
	Catalin Marinas, Will Deacon, Ezequiel Garcia <ezequi>
In-Reply-To: <87608ycwx5.fsf-4ty26DBLk+jEm7gnYqmdkQ@public.gmane.org>

On Fri, 22 Dec 2017 21:47:18 +0100
Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:

> Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
> 
> > Actually remove pxa3xx_nand.c to let marvell_nand.c be compiled instead.
> > Also change the defconfig files using it as well as some board files
> > depending on CONFIG_MTD_NAND_PXA3xx.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>  
> 
> Actually that approach doesn't quite suit me.
> I'm not convinced at all a new rewrite of the driver will be stable right out of
> the box as the old one is.

I would not qualify the old driver as stable, given that we regularly
have bug reports, but I understand your point and kind of understand
your concerns about stability.

> 
> What I would propose instead is :
>  - keep both the new marvell nand driver and the old pxa3xx_nand driver
>  - switch pxa_defconfig to compile them both
>  - continue testing (with my help)
> 
> Once I see the marvell_nand is working properly, we can remove pca3xx_nand in a
> second stage, keeping the pxa platform functional all along.
> 
> Would you agree to that path ?

Hm, I tried this approach already (with Marvell's crypto engine) and it
doesn't quite solve the problem, just delay it a bit until someone
decides to remove the old driver. In my experience, people only start
testing the new driver when they're forced to do it (IOW, when the old
driver is removed and defconfigs are patched to use the new one). So
let's find a way to fix the remaining issues you have instead of
delaying the inevitable.
Note that Miquel has done a lot of testing on various Marvell boards
(mainly mvebu ones since we only have one pxa board). Of course he
couldn't test all possible combinations of NFC <-> NAND, but I'm
quite confident the remaining issues can be fixed quickly with your
help.

> 
> As a side not, this patch should be split into 2 parts :
>  - one for arch/arm -> switch to the new driver
>  - one for drivers/mtd -> removal of the old driver

I agree on that part.

> 
> Cheers.
> 
> --
> Robert

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Boris Brezillon @ 2017-12-22 21:24 UTC (permalink / raw)
  To: Robert Jarzmik
  Cc: Miquel RAYNAL, David Woodhouse, Brian Norris, Marek Vasut,
	Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Russell King, Daniel Mack, Haojian Zhuang, Eric Miao,
	Catalin Marinas, Will Deacon, Ezequiel Garcia <ezequi>
In-Reply-To: <87lghucykr.fsf-4ty26DBLk+jEm7gnYqmdkQ@public.gmane.org>

Hi Robert,

On Fri, 22 Dec 2017 21:11:32 +0100
Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:

> Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
> 
> > Looks like there is a mismatch on the nand bus width detected by the
> > core and the one declared by the driver. Can you try with the following
> > diff applied?  
> 
> Sure.
> 
> Now I get a lot of these message which I didn't have before :
> [   26.897372] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 126976 bytes from PEB 242:4096, read only 126976 bytes, retry
> [   26.928559] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 126976 bytes from PEB 242:4096, read only 126976 bytes, retry
> [   26.959623] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 126976 bytes from PEB 242:4096, read only 126976 bytes, retry
> [   26.990714] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 126976 bytes from PEB 242:4096, read 126976 bytes
> [   27.002084] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc1-00041-ge371e97 #737
> [   27.009674] Hardware name: PXA3xx Platform Development Kit (aka Zylonite)
> [   27.016750] [<c0010440>] (unwind_backtrace) from [<c000df94>] (show_stack+0x10/0x14)
> [   27.024729] [<c000df94>] (show_stack) from [<c02c5bd4>] (ubi_io_read+0x124/0x368)
> [   27.032453] [<c02c5bd4>] (ubi_io_read) from [<c02cd550>] (ubi_attach+0xbd8/0x1868)
> [   27.040148] [<c02cd550>] (ubi_attach) from [<c02be7c4>] (ubi_attach_mtd_dev+0x548/0xe58)
> [   27.048473] [<c02be7c4>] (ubi_attach_mtd_dev) from [<c05526e4>] (ubi_init+0x134/0x1d4)
> [   27.056623] [<c05526e4>] (ubi_init) from [<c00099f8>] (do_one_initcall+0x3c/0x17c)
> [   27.064466] [<c00099f8>] (do_one_initcall) from [<c053fd80>] (kernel_init_freeable+0x104/0x1c0)
> [   27.073398] [<c053fd80>] (kernel_init_freeable) from [<c0423ab8>] (kernel_init+0x8/0xf8)
> [   27.081715] [<c0423ab8>] (kernel_init) from [<c000a780>] (ret_from_fork+0x14/0x34)
> [   27.090115] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 243:2048, read only 64 bytes, retry
> [   27.102363] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 243:2048, read only 64 bytes, retry
> [   27.114586] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 243:2048, read only 64 bytes, retry
> [   27.126813] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 243:2048, read 64 bytes
> [   27.137416] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc1-00041-ge371e97 #737
> [   27.145143] Hardware name: PXA3xx Platform Development Kit (aka Zylonite)
> [   27.152207] [<c0010440>] (unwind_backtrace) from [<c000df94>] (show_stack+0x10/0x14)
> [   27.160037] [<c000df94>] (show_stack) from [<c02c5bd4>] (ubi_io_read+0x124/0x368)
> [   27.167742] [<c02c5bd4>] (ubi_io_read) from [<c02c63dc>] (ubi_io_read_vid_hdr+0x60/0x3ac)
> [   27.176156] [<c02c63dc>] (ubi_io_read_vid_hdr) from [<c02cce58>] (ubi_attach+0x4e0/0x1868)
> [   27.184675] [<c02cce58>] (ubi_attach) from [<c02be7c4>] (ubi_attach_mtd_dev+0x548/0xe58)
> [   27.193010] [<c02be7c4>] (ubi_attach_mtd_dev) from [<c05526e4>] (ubi_init+0x134/0x1d4)
> [   27.201159] [<c05526e4>] (ubi_init) from [<c00099f8>] (do_one_initcall+0x3c/0x17c)
> [   27.208839] [<c00099f8>] (do_one_initcall) from [<c053fd80>] (kernel_init_freeable+0x104/0x1c0)
> [   27.217755] [<c053fd80>] (kernel_init_freeable) from [<c0423ab8>] (kernel_init+0x8/0xf8)
> [   27.226074] [<c0423ab8>] (kernel_init) from [<c000a780>] (ret_from_fork+0x14/0x34)

Looks like a mismatch in the ECC config. Can you check the ecc
strength/step_size in both situation (old driver vs new driver)? Could
you also dump the NDCR register in both cases?

Thanks,

Boris
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 3/5] mtd: nand: replace pxa3xx_nand driver by its rework called marvell_nand
From: Willy Tarreau @ 2017-12-22 22:00 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Mark Rutland, Andrew Lunn, Catalin Marinas, Hanna Hawa,
	Will Deacon, Nadav Haklai, linux-mtd, Robert Jarzmik,
	Richard Weinberger, Russell King, Marek Vasut, Ezequiel Garcia,
	Sebastian Hesselbarth, devicetree, Jason Cooper, Haojian Zhuang,
	Rob Herring, Miquel Raynal, Gregory Clement, Ofer Heifetz,
	linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20171222221032.30f83cb5@bbrezillon>

On Fri, Dec 22, 2017 at 10:10:32PM +0100, Boris Brezillon wrote:
> On Fri, 22 Dec 2017 21:47:18 +0100
> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> > What I would propose instead is :
> >  - keep both the new marvell nand driver and the old pxa3xx_nand driver
> >  - switch pxa_defconfig to compile them both
> >  - continue testing (with my help)
> > 
> > Once I see the marvell_nand is working properly, we can remove pca3xx_nand in a
> > second stage, keeping the pxa platform functional all along.
> > 
> > Would you agree to that path ?
> 
> Hm, I tried this approach already (with Marvell's crypto engine) and it
> doesn't quite solve the problem, just delay it a bit until someone
> decides to remove the old driver. In my experience, people only start
> testing the new driver when they're forced to do it (IOW, when the old
> driver is removed and defconfigs are patched to use the new one). So
> let's find a way to fix the remaining issues you have instead of
> delaying the inevitable.

That also reminds me of the old vs new PATA/IDE drivers a long time ago.
A number of us would stay on the old ones because we were satisfied,
never really making the effort to migrate until it we were really forced.

For the NAND, I think that if the old driver had to coexist with the new
one, at the very least the config option name must change so that it's
not selected by default by make oldconfig, and it's clearly written that
it is not maintained anymore, may be broken and that any one having a
good reason to use it must absolutely contact the maintainer to get the
other one fixed.

Just my two cents,
Willy

^ permalink raw reply

* Re: [PATCH v2 3/5] mtd: nand: replace pxa3xx_nand driver by its rework called marvell_nand
From: Boris Brezillon @ 2017-12-22 22:04 UTC (permalink / raw)
  To: Robert Jarzmik
  Cc: Miquel Raynal, David Woodhouse, Brian Norris, Marek Vasut,
	Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Russell King, Daniel Mack, Haojian Zhuang, Eric Miao,
	Catalin Marinas, Will Deacon, Ezequiel Garcia <ezequi>
In-Reply-To: <87608ycwx5.fsf-4ty26DBLk+jEm7gnYqmdkQ@public.gmane.org>

On Fri, 22 Dec 2017 21:47:18 +0100
Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:

> Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
> 
> > Actually remove pxa3xx_nand.c to let marvell_nand.c be compiled instead.
> > Also change the defconfig files using it as well as some board files
> > depending on CONFIG_MTD_NAND_PXA3xx.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>  
> 
> Actually that approach doesn't quite suit me.
> I'm not convinced at all a new rewrite of the driver will be stable right out of
> the box as the old one is.
> 
> What I would propose instead is :
>  - keep both the new marvell nand driver and the old pxa3xx_nand driver
>  - switch pxa_defconfig to compile them both

Didn't notice you were suggesting to compile both, which doesn't work
because both drivers match the same devices, and only one of them
can actually claim the device (likely the first one to register to the
device model). So, to make it safe you need to have a

	depends on !MTD_NAND_PXA3xx

in your MTD_NAND_MARVELL entry, which means only one driver can be
compiled.

>  - continue testing (with my help)
> 
> Once I see the marvell_nand is working properly, we can remove pca3xx_nand in a
> second stage, keeping the pxa platform functional all along.
> 
> Would you agree to that path ?
> 
> As a side not, this patch should be split into 2 parts :
>  - one for arch/arm -> switch to the new driver
>  - one for drivers/mtd -> removal of the old driver
> 
> Cheers.
> 
> --
> Robert

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 1/6] dt-bindings: soc: qcom: Add label for GLINK bindings
From: Bjorn Andersson @ 2017-12-22 22:28 UTC (permalink / raw)
  To: Rob Herring
  Cc: Chris Lew, andy.gross, david.brown, aneela, linux-arm-msm,
	linux-remoteproc, linux-soc, devicetree, linux-kernel
In-Reply-To: <20171220183000.rhxgyikfqzxmqkjo@rob-hp-laptop>

On Wed 20 Dec 10:30 PST 2017, Rob Herring wrote:

> On Mon, Dec 18, 2017 at 02:02:09PM -0800, Chris Lew wrote:
> > Add a label property to identify the edge this node represents.
> 
> Why does a user need to know this?
> 

Each SMD or GLINK edge will expose a dev node as /dev/rpmsg_ctrlX that
can be used create dev nodes for channels that user space wants to
access directly (without a specific kernel driver).

The problem is that there's currently nothing in the device hierarchy
that identifies which edge, and hence remoteproc, these channels are
associated with.

So for SMD I added the ability to specify a "label" on the SMD edge,
which is propagated in sysfs and allows me to write udev rules creating
symlinks based on the edge name (e.g. /dev/modem/DIAG vs /dev/rpmsg4)
and it also allows user space tools to figure out which channels comes
from the same edge/remoteproc (e.g. which DIAG control channel is
related to which DIAG data channel).

This patch attempts to add the equivalent property on GLINK edges.


As SMD and GLINK edges can exist without a parent remoteproc (e.g. for
the always-on subsystems) and it's possible for a single remoteproc to
have multiple edges, it's inadequate to put this label on the
remoteproc.


PS. Downstream solutions of remoteproc + virtio-rpmsg has "solved" this
problem by using aliases for remoteprocs and then only allow one
virtio-rpmsg node per remoteproc, to get deterministic identification of
channels.

Regards,
Bjorn

^ permalink raw reply

* Re: [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Miquel RAYNAL @ 2017-12-22 22:37 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Robert Jarzmik, David Woodhouse, Brian Norris, Marek Vasut,
	Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Russell King, Daniel Mack, Haojian Zhuang, Eric Miao,
	Catalin Marinas, Will Deacon,
	Ezequiel Garcia <ezequiel.garcia>
In-Reply-To: <20171222222441.0fd77df9@bbrezillon>

Hi Robert,

On Fri, 22 Dec 2017 22:24:41 +0100
Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Hi Robert,
> 
> On Fri, 22 Dec 2017 21:11:32 +0100
> Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:
> 
> > Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
> >   
> > > Looks like there is a mismatch on the nand bus width detected by
> > > the core and the one declared by the driver. Can you try with the
> > > following diff applied?    
> > 
> > Sure.
> > 
> > Now I get a lot of these message which I didn't have before :
> > [   26.897372] ubi0 warning: ubi_io_read: error -74 (ECC error)
> > while reading 126976 bytes from PEB 242:4096, read only 126976
> > bytes, retry [   26.928559] ubi0 warning: ubi_io_read: error -74
> > (ECC error) while reading 126976 bytes from PEB 242:4096, read only
> > 126976 bytes, retry [   26.959623] ubi0 warning: ubi_io_read: error
> > -74 (ECC error) while reading 126976 bytes from PEB 242:4096, read
> > only 126976 bytes, retry [   26.990714] ubi0 error: ubi_io_read:
> > error -74 (ECC error) while reading 126976 bytes from PEB 242:4096,
> > read 126976 bytes [   27.002084] CPU: 0 PID: 1 Comm: swapper Not
> > tainted 4.15.0-rc1-00041-ge371e97 #737 [   27.009674] Hardware
> > name: PXA3xx Platform Development Kit (aka Zylonite) [   27.016750]
> > [<c0010440>] (unwind_backtrace) from [<c000df94>]
> > (show_stack+0x10/0x14) [   27.024729] [<c000df94>] (show_stack)
> > from [<c02c5bd4>] (ubi_io_read+0x124/0x368) [   27.032453]
> > [<c02c5bd4>] (ubi_io_read) from [<c02cd550>]
> > (ubi_attach+0xbd8/0x1868) [   27.040148] [<c02cd550>] (ubi_attach)
> > from [<c02be7c4>] (ubi_attach_mtd_dev+0x548/0xe58) [   27.048473]
> > [<c02be7c4>] (ubi_attach_mtd_dev) from [<c05526e4>]
> > (ubi_init+0x134/0x1d4) [   27.056623] [<c05526e4>] (ubi_init) from
> > [<c00099f8>] (do_one_initcall+0x3c/0x17c) [   27.064466]
> > [<c00099f8>] (do_one_initcall) from [<c053fd80>]
> > (kernel_init_freeable+0x104/0x1c0) [   27.073398] [<c053fd80>]
> > (kernel_init_freeable) from [<c0423ab8>] (kernel_init+0x8/0xf8)
> > [   27.081715] [<c0423ab8>] (kernel_init) from [<c000a780>]
> > (ret_from_fork+0x14/0x34) [   27.090115] ubi0 warning: ubi_io_read:
> > error -74 (ECC error) while reading 64 bytes from PEB 243:2048,
> > read only 64 bytes, retry [   27.102363] ubi0 warning: ubi_io_read:
> > error -74 (ECC error) while reading 64 bytes from PEB 243:2048,
> > read only 64 bytes, retry [   27.114586] ubi0 warning: ubi_io_read:
> > error -74 (ECC error) while reading 64 bytes from PEB 243:2048,
> > read only 64 bytes, retry [   27.126813] ubi0 error: ubi_io_read:
> > error -74 (ECC error) while reading 64 bytes from PEB 243:2048,
> > read 64 bytes [   27.137416] CPU: 0 PID: 1 Comm: swapper Not
> > tainted 4.15.0-rc1-00041-ge371e97 #737 [   27.145143] Hardware
> > name: PXA3xx Platform Development Kit (aka Zylonite) [   27.152207]
> > [<c0010440>] (unwind_backtrace) from [<c000df94>]
> > (show_stack+0x10/0x14) [   27.160037] [<c000df94>] (show_stack)
> > from [<c02c5bd4>] (ubi_io_read+0x124/0x368) [   27.167742]
> > [<c02c5bd4>] (ubi_io_read) from [<c02c63dc>]
> > (ubi_io_read_vid_hdr+0x60/0x3ac) [   27.176156] [<c02c63dc>]
> > (ubi_io_read_vid_hdr) from [<c02cce58>] (ubi_attach+0x4e0/0x1868)
> > [   27.184675] [<c02cce58>] (ubi_attach) from [<c02be7c4>]
> > (ubi_attach_mtd_dev+0x548/0xe58) [   27.193010] [<c02be7c4>]
> > (ubi_attach_mtd_dev) from [<c05526e4>] (ubi_init+0x134/0x1d4)
> > [   27.201159] [<c05526e4>] (ubi_init) from [<c00099f8>]
> > (do_one_initcall+0x3c/0x17c) [   27.208839] [<c00099f8>]
> > (do_one_initcall) from [<c053fd80>]
> > (kernel_init_freeable+0x104/0x1c0) [   27.217755] [<c053fd80>]
> > (kernel_init_freeable) from [<c0423ab8>] (kernel_init+0x8/0xf8)
> > [   27.226074] [<c0423ab8>] (kernel_init) from [<c000a780>]
> > (ret_from_fork+0x14/0x34)  
> 
> Looks like a mismatch in the ECC config. Can you check the ecc
> strength/step_size in both situation (old driver vs new driver)?

For that, you might want to add traces in marvell_nand_ecc_init() and
marvell_nand_hw_ecc_ctrl_init().

> Could you also dump the NDCR register in both cases?

NDCR register (as well as NDCBx registers) will appear if you let

    #define DEBUG

at the beginning of the driver.

Also, can you please give us the entire dmesg (I mean the boot, not the
flow of UBIFS errors of course).

If this, in conjunction with your check of the ECC configuration, does
not give satisfying results, I will write a test script using
nandwrite/nanddump/flash_erase.

Thank you,
Miquèl


> 
> Thanks,
> 
> Boris



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Miquel RAYNAL @ 2017-12-22 22:50 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Robert Jarzmik, David Woodhouse, Brian Norris, Marek Vasut,
	Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Russell King, Daniel Mack, Haojian Zhuang, Eric Miao,
	Catalin Marinas, Will Deacon,
	Ezequiel Garcia <ezequiel.garcia>
In-Reply-To: <20171222233730.68d9cb9d@xps13>

On Fri, 22 Dec 2017 23:37:30 +0100
Miquel RAYNAL <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Hi Robert,
> 
> On Fri, 22 Dec 2017 22:24:41 +0100
> Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> 
> > Hi Robert,
> > 
> > On Fri, 22 Dec 2017 21:11:32 +0100
> > Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:
> > 
> > > Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
> > >   
> > > > Looks like there is a mismatch on the nand bus width detected by
> > > > the core and the one declared by the driver. Can you try with
> > > > the following diff applied?    
> > > 
> > > Sure.
> > > 
> > > Now I get a lot of these message which I didn't have before :
> > > [   26.897372] ubi0 warning: ubi_io_read: error -74 (ECC error)
> > > while reading 126976 bytes from PEB 242:4096, read only 126976
> > > bytes, retry [   26.928559] ubi0 warning: ubi_io_read: error -74
> > > (ECC error) while reading 126976 bytes from PEB 242:4096, read
> > > only 126976 bytes, retry [   26.959623] ubi0 warning:
> > > ubi_io_read: error -74 (ECC error) while reading 126976 bytes
> > > from PEB 242:4096, read only 126976 bytes, retry [   26.990714]
> > > ubi0 error: ubi_io_read: error -74 (ECC error) while reading
> > > 126976 bytes from PEB 242:4096, read 126976 bytes [   27.002084]
> > > CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc1-00041-ge371e97
> > > #737 [   27.009674] Hardware name: PXA3xx Platform Development
> > > Kit (aka Zylonite) [   27.016750] [<c0010440>] (unwind_backtrace)
> > > from [<c000df94>] (show_stack+0x10/0x14) [   27.024729]
> > > [<c000df94>] (show_stack) from [<c02c5bd4>]
> > > (ubi_io_read+0x124/0x368) [   27.032453] [<c02c5bd4>]
> > > (ubi_io_read) from [<c02cd550>] (ubi_attach+0xbd8/0x1868)
> > > [   27.040148] [<c02cd550>] (ubi_attach) from [<c02be7c4>]
> > > (ubi_attach_mtd_dev+0x548/0xe58) [   27.048473] [<c02be7c4>]
> > > (ubi_attach_mtd_dev) from [<c05526e4>] (ubi_init+0x134/0x1d4)
> > > [   27.056623] [<c05526e4>] (ubi_init) from [<c00099f8>]
> > > (do_one_initcall+0x3c/0x17c) [   27.064466] [<c00099f8>]
> > > (do_one_initcall) from [<c053fd80>]
> > > (kernel_init_freeable+0x104/0x1c0) [   27.073398] [<c053fd80>]
> > > (kernel_init_freeable) from [<c0423ab8>] (kernel_init+0x8/0xf8)
> > > [   27.081715] [<c0423ab8>] (kernel_init) from [<c000a780>]
> > > (ret_from_fork+0x14/0x34) [   27.090115] ubi0 warning:
> > > ubi_io_read: error -74 (ECC error) while reading 64 bytes from
> > > PEB 243:2048, read only 64 bytes, retry [   27.102363] ubi0
> > > warning: ubi_io_read: error -74 (ECC error) while reading 64
> > > bytes from PEB 243:2048, read only 64 bytes, retry [   27.114586]
> > > ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64
> > > bytes from PEB 243:2048, read only 64 bytes, retry [   27.126813]
> > > ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64
> > > bytes from PEB 243:2048, read 64 bytes [   27.137416] CPU: 0 PID:
> > > 1 Comm: swapper Not tainted 4.15.0-rc1-00041-ge371e97 #737
> > > [   27.145143] Hardware name: PXA3xx Platform Development Kit
> > > (aka Zylonite) [   27.152207] [<c0010440>] (unwind_backtrace)
> > > from [<c000df94>] (show_stack+0x10/0x14) [   27.160037]
> > > [<c000df94>] (show_stack) from [<c02c5bd4>]
> > > (ubi_io_read+0x124/0x368) [   27.167742] [<c02c5bd4>]
> > > (ubi_io_read) from [<c02c63dc>] (ubi_io_read_vid_hdr+0x60/0x3ac)
> > > [   27.176156] [<c02c63dc>] (ubi_io_read_vid_hdr) from
> > > [<c02cce58>] (ubi_attach+0x4e0/0x1868) [   27.184675]
> > > [<c02cce58>] (ubi_attach) from [<c02be7c4>]
> > > (ubi_attach_mtd_dev+0x548/0xe58) [   27.193010] [<c02be7c4>]
> > > (ubi_attach_mtd_dev) from [<c05526e4>] (ubi_init+0x134/0x1d4)
> > > [   27.201159] [<c05526e4>] (ubi_init) from [<c00099f8>]
> > > (do_one_initcall+0x3c/0x17c) [   27.208839] [<c00099f8>]
> > > (do_one_initcall) from [<c053fd80>]
> > > (kernel_init_freeable+0x104/0x1c0) [   27.217755] [<c053fd80>]
> > > (kernel_init_freeable) from [<c0423ab8>] (kernel_init+0x8/0xf8)
> > > [   27.226074] [<c0423ab8>] (kernel_init) from [<c000a780>]
> > > (ret_from_fork+0x14/0x34)  
> > 
> > Looks like a mismatch in the ECC config. Can you check the ecc
> > strength/step_size in both situation (old driver vs new driver)?
> 
> For that, you might want to add traces in marvell_nand_ecc_init() and
> marvell_nand_hw_ecc_ctrl_init().
> 
> > Could you also dump the NDCR register in both cases?
> 
> NDCR register (as well as NDCBx registers) will appear if you let
> 
>     #define DEBUG
> 
> at the beginning of the driver.
> 
> Also, can you please give us the entire dmesg (I mean the boot, not
> the flow of UBIFS errors of course).
> 
> If this, in conjunction with your check of the ECC configuration, does
> not give satisfying results, I will write a test script using
> nandwrite/nanddump/flash_erase.

Something else:
Do you use platform data or device tree? Can you show where the board
information are?

I guess you tried to compile from the top of the branch, could you try
right after the addition of marvell_nand.c, bypassing the pdata/DT
changes.

Thanks,
Miquèl

> 
> Thank you,
> Miquèl
> 
> 
> > 
> > Thanks,
> > 
> > Boris
> 
> 
> 



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH] mmc: Don't reference Linux-specific OF_GPIO_ACTIVE_LOW flag in DT binding
From: Tuomas Tynkkynen @ 2017-12-23  0:34 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Rob Herring, Mark Rutland, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Tuomas Tynkkynen

OF_GPIO_ACTIVE_LOW is a Linux implementation detail. The binding
document should be referring to GPIO_ACTIVE_LOW found in
include/dt-bindings/gpio/gpio.h.

Signed-off-by: Tuomas Tynkkynen <tuomas-yrGDUoBaLx3QT0dZR+AlfA@public.gmane.org>
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index fb11ae8b3b72..467cd7b147ce 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -67,10 +67,10 @@ logic applies to the "wp-inverted" property.
 CD and WP lines can be implemented on the hardware in one of two ways: as GPIOs,
 specified in cd-gpios and wp-gpios properties, or as dedicated pins. Polarity of
 dedicated pins can be specified, using *-inverted properties. GPIO polarity can
-also be specified using the OF_GPIO_ACTIVE_LOW flag. This creates an ambiguity
+also be specified using the GPIO_ACTIVE_LOW flag. This creates an ambiguity
 in the latter case. We choose to use the XOR logic for GPIO CD and WP lines.
 This means, the two properties are "superimposed," for example leaving the
-OF_GPIO_ACTIVE_LOW flag clear and specifying the respective *-inverted
+GPIO_ACTIVE_LOW flag clear and specifying the respective *-inverted property
 property results in a double-inversion and actually means the "normal" line
 polarity is in effect.
 
-- 
2.15.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller
From: Jassi Brar @ 2017-12-23  4:57 UTC (permalink / raw)
  To: Georgi Djakov
  Cc: Stephen Boyd, Bjorn Andersson, Michael Turquette, Rob Herring,
	linux-clk, Linux Kernel Mailing List, linux-arm-msm,
	Devicetree List
In-Reply-To: <20171205154701.27730-3-georgi.djakov@linaro.org>

On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
> There is a clock controller functionality provided by the APCS hardware
> block of msm8916 devices. The device-tree would represent an APCS node
> with both mailbox and clock provider properties.
>
The spec might depict a 'clock' box and 'mailbox' box inside the
bigger APCS box. However, from the code I see in this patchset, they
are orthogonal and can & should be represented as independent DT
nodes.
Patch-1 is ok, though.

Thanks

^ permalink raw reply

* [PATCHv4 0/3] Socionext Synquacer NETSEC driver
From: jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w @ 2017-12-23  5:44 UTC (permalink / raw)
  To: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
  Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A, andrew-g2DYL2Zd6BY,
	ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	masami.hiramatsu-QSEj5FYQhm4dnm+yROfE0A, Jassi Brar

From: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Hi,

Changes since v3
	# Discard 'socionext,snq-mdio', and simply use 'mdio' subnode.
	# Use ioremap on ucode region as well, instead of memremap.

Changes since v2
        # Use 'mdio' subnode in DT bindings.
        # Use phy_interface_mode_is_rgmii(), instead of open coding the check.
        # Use readl/b with eeprom_base pointer.
        # Unregister mdio bus upon failure in probe.

Changes since v1
        # Switched from using memremap to ioremap
        # Implemented ndo_do_ioctl callback
        # Defined optional 'dma-coherent' DT property

Jassi Brar (3):
  dt-bindings: net: Add DT bindings for Socionext Netsec
  net: socionext: Add Synquacer NetSec driver
  MAINTAINERS: Add entry for Socionext ethernet driver

 .../devicetree/bindings/net/socionext-netsec.txt   |   55 +
 MAINTAINERS                                        |    7 +
 drivers/net/ethernet/Kconfig                       |    1 +
 drivers/net/ethernet/Makefile                      |    1 +
 drivers/net/ethernet/socionext/Kconfig             |   29 +
 drivers/net/ethernet/socionext/Makefile            |    1 +
 drivers/net/ethernet/socionext/netsec.c            | 1844 ++++++++++++++++++++
 7 files changed, 1938 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/socionext-netsec.txt
 create mode 100644 drivers/net/ethernet/socionext/Kconfig
 create mode 100644 drivers/net/ethernet/socionext/Makefile
 create mode 100644 drivers/net/ethernet/socionext/netsec.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox