* Re: [PATCH linux v5 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver
From: Rob Herring @ 2017-03-30 22:46 UTC (permalink / raw)
To: Jaghathiswari Rankappagounder Natarajan
Cc: joel, jdelvare, linux, linux-hwmon, linux-kernel, openbmc, corbet,
linux-doc, mark.rutland, devicetree
In-Reply-To: <20170324181723.29379-2-jaghu@google.com>
On Fri, Mar 24, 2017 at 11:17:22AM -0700, Jaghathiswari Rankappagounder Natarajan wrote:
> This binding provides interface for adding values related to ASPEED
> AST2400/2500 PWM and Fan tach controller support.
> The PWM controller can support upto 8 PWM output ports.
> The Fan tach controller can support upto 16 tachometer inputs.
>
> Signed-off-by: Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>
> ---
> v5:
> - Changed the naming scheme to aspeed,ast2400/2500-pwm-tacho
> - Removed gpio pin muxing
> - Added aspeed vendor prefix for fan-tach-ch
> - Changed to fan@0/1
> - Changed reg to 32 bits
>
> v4:
> - Used 'reg'
>
> v3:
> - Made the structure more common
>
> v2:
> - Removed '_' in node and property names
> - Gave some explanation for the properties used
>
> .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
> new file mode 100644
> index 000000000000..f96d32bfcdfa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
> @@ -0,0 +1,68 @@
> +ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
> +
> +The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan Tacho
> +controller can support upto 16 Fan tachometer inputs.
> +
> +There can be upto 8 fans supported. Each fan can have one PWM output and
> +one/two Fan tach inputs.
> +
> +Required properties for pwm-tacho node:
> +- #address-cells : should be 1.
> +
> +- #size-cells : should be 1.
> +
> +- reg : address and length of the register set for the device.
> +
> +- pinctrl-names : a pinctrl state named "default" must be defined.
> +
> +- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
> +
> +- compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
> + "aspeed,ast2500-pwm-tacho" for AST2500.
> +
> +- clocks : a fixed clock providing input clock frequency(PWM
> + and Fan Tach clock)
> +
> +fan subnode format:
> +===================
> +Under fan subnode there can upto 8 child nodes, with each child node
> +representing a fan. If there are 8 fans each fan can have one PWM port and
> +one/two Fan tach inputs.
> +
> +Required properties for each child node:
> +- reg : should specify PWM source port.
> + integer value in the range 0 to 7 with 0 indicating PWM port A and
> + 7 indicating PWM port H.
> +
> +- aspeed-fan-tach-ch : should specify the Fan tach input channel.
aspeed,fan-tach-ch
With that,
Acked-by: Rob Herring <robh@kernel.org>
> + integer value in the range 0 through 15, with 0 indicating
> + Fan tach channel 0 and 15 indicating Fan tach channel 15.
> + Atleast one Fan tach input channel is required.
> +
> +Examples:
> +
> +pwm_tacho_fixed_clk: fixedclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <24000000>;
> +}
> +
> +pwm_tacho: pwmtachocontroller@1e786000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x1E786000 0x1000>;
> + compatible = "aspeed,ast2500-pwm-tacho";
> + clocks = <&pwm_tacho_fixed_clk>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
> +
> + fan@0 {
> + reg = <0x00>;
> + aspeed-fan-tach-ch = /bits/ 8 <0x00>;
> + };
> +
> + fan@1 {
> + reg = <0x01>;
> + aspeed-fan-tach-ch = /bits/ 8 <0x01 0x02>;
> + };
> +};
> --
> 2.12.1.578.ge9c3154ca4-goog
>
^ permalink raw reply
* Re: [PATCH 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler
From: Rob Herring @ 2017-03-30 22:44 UTC (permalink / raw)
To: Alan Tull
Cc: Greg Kroah-Hartman, Moritz Fischer,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA, Moritz Fischer, Michal Simek,
Sören Brinkmann, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170324153321.4168-2-atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Fri, Mar 24, 2017 at 10:33:20AM -0500, Alan Tull wrote:
> From: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Please use "dt-bindings: fpga: ..." for the subject.
>
> This adds the binding documentation for the Xilinx LogiCORE PR
> Decoupler soft core.
>
> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> Acked-by: Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
I'm confused why you are sending these instead of Moritz? If it goes
through you, then it should have your S-o-B too.
> Cc: Sören Brinkmann <soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> .../bindings/fpga/xilinx-pr-decoupler.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> new file mode 100644
> index 000000000000..2c527ac30398
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> @@ -0,0 +1,35 @@
> +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
> +
> +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
> +decouplers / fpga bridges.
> +The controller can decouple/disable the bridges which prevents signal
> +changes from passing through the bridge. The controller can also
> +couple / enable the bridges which allows traffic to pass through the
> +bridge normally.
> +
> +The Driver supports only MMIO handling. A PR region can have multiple
> +PR Decouplers which can be handled independently or chained via decouple/
> +decouple_status signals.
> +
> +Required properties:
> +- compatible : Should contain "xlnx,pr-decoupler-1.00" or "xlnx,pr-decoupler"
I'd drop xlnx,pr-decoupler, but in any case, it should not be OR rather
"followed by". Plus the example has both.
> +- regs : base address and size for decoupler module
> +- clocks : input clock to IP
> +- clock-names : should contain "aclk"
> +
> +Optional properties:
> +- bridge-enable : 0 if driver should disable bridge at startup
> + 1 if driver should enable bridge at startup
> + Default is to leave bridge in current state.
> +
> +See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic bindings.
> +
> +Example:
> + fpga-bridge@100000450 {
> + compatible = "xlnx,pr-decoupler-1.00",
> + "xlnx-pr-decoupler";
> + regs = <0x10000045 0x10>;
> + clocks = <&clkc 15>;
> + clock-names = "aclk";
> + bridge-enable = <0>;
> + };
> --
> 2.11.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
--
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/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc
From: Rob Herring @ 2017-03-30 22:39 UTC (permalink / raw)
To: Jacopo Mondi
Cc: geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490368934-12494-3-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
On Fri, Mar 24, 2017 at 04:22:09PM +0100, Jacopo Mondi wrote:
> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> controller.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
> ---
> .../bindings/pinctrl/renesas,rza1-pinctrl.txt | 143 +++++++++++++++++++++
> 1 file changed, 143 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 1/2] clk: qcom: Update DT bindings for MSM8660 LCC
From: Rob Herring @ 2017-03-30 22:31 UTC (permalink / raw)
To: Linus Walleij
Cc: Michael Turquette, Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170324082424.6143-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Fri, Mar 24, 2017 at 09:24:24AM +0100, Linus Walleij wrote:
> This adds the right compatible string and header for the
> MSM8660 LCC and some new defines to the dt-bindings header.
>
> Take this opportunity to spell out the acronym LPASS for
> Low-power Audio Subsystem.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/clock/qcom,lcc.txt | 5 +--
> include/dt-bindings/clock/qcom,lcc-msm8660.h | 40 ++++++++++++++++++++++
> 2 files changed, 43 insertions(+), 2 deletions(-)
> create mode 100644 include/dt-bindings/clock/qcom,lcc-msm8660.h
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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] Documentation: dt: Add binding for /secure-chosen/stdout-path
From: Rob Herring @ 2017-03-30 22:28 UTC (permalink / raw)
To: Jerome Forissier
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
jens.wiklander-QSEj5FYQhm4dnm+yROfE0A,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A,
peter.maydell-QSEj5FYQhm4dnm+yROfE0A, robin.murphy-5wv7dgnIgG8
In-Reply-To: <e3e007ef9ee6a622ae4ccc74fd0fca32b3c5dfb5.1488531370.git.jerome.forissier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Fri, Mar 03, 2017 at 10:24:33AM +0100, Jerome Forissier wrote:
> Some platforms may use a single device tree to describe two address
> spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
> for Secure-only devices"). For these platforms it makes sense to define
> a secure counterpart of /chosen, namely: /secure-chosen. This new node
> is meant to be used by the secure firmware to pass data to the secure
> OS. Only the stdout-path property is supported for now.
>
> Signed-off-by: Jerome Forissier <jerome.forissier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/secure.txt | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> v2
>
> - Clarify the expected behavior when /secure-chosen/stdout-path is not
> present (either the property or the node itself), as proposed by Peter
> and Robin. Note that I have made the fallback to /chosen optional.
I'm okay with this, but would like to hold off merging it until your are
really using it. You did say you were "experimenting" and it doesn't
sound like the DT usage in secure world is that far along. I just want
to see if there are other issues that come up.
Rob
--
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 2/2] dt-bindings: mtd: document linux,part-probe property
From: Rafał Miłecki @ 2017-03-30 21:53 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170330215332.32699-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Support for this property has been introduced in 2010 with commit
9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
parition probe") but it was never documented. Fix this by adding a
proper description and example.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
index fc068b923d7a..1ada70e718b2 100644
--- a/Documentation/devicetree/bindings/mtd/common.txt
+++ b/Documentation/devicetree/bindings/mtd/common.txt
@@ -6,10 +6,17 @@ Optional properties:
controller based name) in order to ease flash device identification
and/or describe what they are used for.
+- linux,part-probe: if present, this property should contain a list of strings
+ with partition probes to be used for the flash device. A role of partition
+ probe (parser) is to read/construct partition table and register found
+ partitions. Getting partition table may be platform or device specific so
+ various devices may use various Linux drivers for this purpose.
+
Example:
flash@0 {
label = "System-firmware";
+ linux,part-probe = "cmdlinepart", "ofpart";
/* flash type specific properties */
};
--
2.11.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 1/2] mtd: move code reading DT specified part probes to the common place
From: Rafał Miłecki @ 2017-03-30 21:53 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Handling (creating) partitions for flash devices requires using a proper
driver that will read partition table (out of somewhere). We can't
simply try all existing drivers one by one, so MTD subsystem allows
drivers to specify a list of applicable part probes.
So far physmap_of was the only driver with support for linux,part-probe
DT property. Other ones had list or probes hardcoded which wasn't making
them really flexible. It prevented using common flash drivers on
platforms that required some specific partition table access.
This commit moves support for mentioned DT property to the common place
so it can be reused by other drivers.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
This patch is based on top of
[PATCH] mtd: physmap_of: use OF helpers for reading strings
---
drivers/mtd/maps/physmap_of.c | 39 ++++++---------------------------------
drivers/of/Kconfig | 6 ++++++
drivers/of/Makefile | 1 +
drivers/of/of_mtd.c | 30 ++++++++++++++++++++++++++++++
include/linux/of_mtd.h | 25 +++++++++++++++++++++++++
5 files changed, 68 insertions(+), 33 deletions(-)
create mode 100644 drivers/of/of_mtd.c
create mode 100644 include/linux/of_mtd.h
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 62fa6836f218..fa54c07eb118 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -22,6 +22,7 @@
#include <linux/mtd/concat.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <linux/of_mtd.h>
#include <linux/of_platform.h>
#include <linux/slab.h>
#include "physmap_of_gemini.h"
@@ -114,33 +115,6 @@ static struct mtd_info *obsolete_probe(struct platform_device *dev,
static const char * const part_probe_types_def[] = {
"cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
-static const char * const *of_get_probes(struct device_node *dp)
-{
- const char **res;
- int count;
-
- count = of_property_count_strings(dp, "linux,part-probe");
- if (count < 0)
- return part_probe_types_def;
-
- res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
- if (!res)
- return NULL;
-
- count = of_property_read_string_array(dp, "linux,part-probe", res,
- count);
- if (count < 0)
- return NULL;
-
- return res;
-}
-
-static void of_free_probes(const char * const *probes)
-{
- if (probes != part_probe_types_def)
- kfree(probes);
-}
-
static const struct of_device_id of_flash_match[];
static int of_flash_probe(struct platform_device *dev)
{
@@ -310,14 +284,13 @@ static int of_flash_probe(struct platform_device *dev)
info->cmtd->dev.parent = &dev->dev;
mtd_set_of_node(info->cmtd, dp);
- part_probe_types = of_get_probes(dp);
- if (!part_probe_types) {
- err = -ENOMEM;
- goto err_out;
- }
+ part_probe_types = of_mtd_get_probes(dp);
+ if (!part_probe_types)
+ part_probe_types = part_probe_types_def;
mtd_device_parse_register(info->cmtd, part_probe_types, NULL,
NULL, 0);
- of_free_probes(part_probe_types);
+ if (part_probe_types != part_probe_types_def)
+ of_mtd_free_probes(part_probe_types);
kfree(mtd_list);
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index ba7b034b2b91..18ac835a1ce4 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -78,6 +78,12 @@ config OF_MDIO
help
OpenFirmware MDIO bus (Ethernet PHY) accessors
+config OF_MTD
+ def_tristate MTD
+ depends on MTD
+ help
+ OpenFirmware MTD accessors
+
config OF_PCI
def_tristate PCI
depends on PCI
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index d7efd9d458aa..965c2a691337 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_OF_IRQ) += irq.o
obj-$(CONFIG_OF_NET) += of_net.o
obj-$(CONFIG_OF_UNITTEST) += unittest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
+obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
new file mode 100644
index 000000000000..ff851d7742d5
--- /dev/null
+++ b/drivers/of/of_mtd.c
@@ -0,0 +1,30 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/of.h>
+#include <linux/of_mtd.h>
+
+const char * const *of_mtd_get_probes(struct device_node *np)
+{
+ const char **res;
+ int count;
+
+ count = of_property_count_strings(np, "linux,part-probe");
+ if (count < 0)
+ return NULL;
+
+ res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
+ if (!res)
+ return NULL;
+
+ count = of_property_read_string_array(np, "linux,part-probe", res,
+ count);
+ if (count < 0)
+ return NULL;
+
+ return res;
+}
+EXPORT_SYMBOL(of_mtd_get_probes);
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
new file mode 100644
index 000000000000..d55f4aa684c5
--- /dev/null
+++ b/include/linux/of_mtd.h
@@ -0,0 +1,25 @@
+#ifndef __OF_MTD_H
+#define __OF_MTD_H
+
+#include <linux/slab.h>
+
+struct device_node;
+
+#ifdef CONFIG_OF_MTD
+const char * const *of_mtd_get_probes(struct device_node *np);
+static inline void of_mtd_free_probes(const char * const *probes)
+{
+ kfree(probes);
+}
+#else
+const char * const *of_mtd_get_probes(struct device_node *np)
+{
+ return NULL;
+}
+
+static inline void of_mtd_free_probes(const char * const *probes)
+{
+}
+#endif
+
+#endif
--
2.11.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 1/2] drm/bridge: ti-tfp410: support hpd via gpio
From: Christopher Spinrath @ 2017-03-30 21:51 UTC (permalink / raw)
To: Archit Taneja, Jyri Sarha
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Airlie, Fabio Estevam, Russell King - ARM Linux,
DRI mailing list, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Igor Grinberg, Sascha Hauer, Fabio Estevam, Shawn Guo,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <e63e628794b044c2a615091697622d50-cBaz+nnMw18umhiu9RXYRl5UTUQ924AY@public.gmane.org>
Hi,
On 03/30/2017 11:49 AM, Archit Taneja wrote:
>
>
> On 03/28/2017 07:02 PM, Jyri Sarha wrote:
>> On 03/27/17 08:58, Archit Taneja wrote:
>>> Hi,
>>>
>>> On 03/07/2017 03:21 AM, Christopher Spinrath wrote:
>>>> Hi Fabio,
>>>>
>>>> On 03/06/2017 10:46 PM, Fabio Estevam wrote:
>>>>> Hi Christopher,
>>>>>
>>>>> On Mon, Mar 6, 2017 at 6:40 PM,
>>>>> <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> wrote:
>>>>>> From: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>>>>>>
>>>>>> On some boards the hpd pin of a hdmi connector is wired up to a gpio
>>>>>> pin. Since in the DRM world the tfp410 driver is responsible for
>>>>>> handling the connector, add support for hpd gpios in this very
>>>>>> driver.
>>>>>>
>>>>>> Signed-off-by: Christopher Spinrath
>>>>>> <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>>>>>> ---
>>>>>> drivers/gpu/drm/bridge/ti-tfp410.c | 72
>>>>>> ++++++++++++++++++++++++++++++++++++--
>>>>>
>> ...
>>>>
>>>
>>> The patch looks good to me.
>>>
>>> Jyri,
>>>
>>> Is it possible for you to verify this on Beaglebone platform?
>>>
>>
>> If I read my BeagleBone DVI-D Cape docs right, it does not have the HPD
>> pin connected. At least it does not mention any gpio that could be used
>> for the purpose. So I can not easily test this patch in real world
>> situation. For what it is worth the patch looks ok to me too.
>
> Thanks for the review. I looked at the tfp410 data sheet[1], there isn't
> a HPD pin on the chip at all. My guess is that boards using tfp410 most
> likely have the HPD pin routed to the SoC from the HDMI connector
> (with a level shifter/shield in between).
Exactly. I tried to say that in the commit message (and, actually,
that's what I did in Patch 2/2 for the Utilite Pro).
Thanks,
Christopher
> We would eventually need to move the both ddc and hpd stuff to
> a generic hdmi connector driver later on. I've queued this to
> drm-misc-next.
>
> [1]: http://www.ti.com/lit/ds/symlink/tfp410.pdf
>
> Archit
>
>>
>> Best regards,
>> Jyri
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
--
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 V8 0/7] LPC: legacy ISA I/O support
From: dann frazier @ 2017-03-30 21:42 UTC (permalink / raw)
To: zhichang.yuan
Cc: Catalin Marinas, Will Deacon, Rob Herring, Frank Rowand,
Bjorn Helgaas, rafael, Arnd Bergmann, linux-arm-kernel,
Mark Rutland, devicetree@vger.kernel.org, lorenzo.pieralisi,
Gabriele Paoloni, Corey Minyard, benh, John Garry,
linux-kernel@vger.kernel.org, xuwei5, linuxarm, linux-acpi,
Zou Rongrong, linux-pci, olof
In-Reply-To: <1490887619-61732-1-git-send-email-yuanzhichang@hisilicon.com>
On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan
<yuanzhichang@hisilicon.com> wrote:
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.
> -----------
> | LPC host|
> | |
> -----------
> |
> _____________V_______________LPC
> | |
> V V
> ------------
> | BT(ipmi)|
> ------------
>
> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a specific
> LPC driver is needed to make LPC host generate the standard LPC I/O cycles with
> the target peripherals'I/O port addresses. But on curent arm64 world, there is
> no real I/O accesses. All the I/O operations through in/out pair are based on
> MMIO which is not satisfied the I/O mechanism on Hip06/Hip07 LPC.
> To solve this issue and keep the relevant existing peripherals' driver
> untouched, this patchset implements:
> - introduces a generic I/O space management framwork, LIBIO, to support I/O
> operations of both MMIO buses and the host controllers which access their
> peripherals with host local I/O addresses;
> - redefines the in/out accessors to provide unified interfaces for MMIO and
> legacy I/O. Based on the LIBIO, the calling of in/out() from upper-layer
> drivers, such as ipmi-si, will be redirected to the corresponding
> device-specific I/O hooks to perfrom the I/O accesses.
> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals can
> be supported without any changes on the existing ipmi-si driver.
>
> Changes from V7:
> - Based on Arnd's comment, rename the LIBIO as LOGIC_PIO;
> - Improved the mapping process in LOGIC_PIO to gain better efficiency when
> redirecting the I/O accesses to right device driver;
> - To reduce the impact on PCI MMIO to a minimum, add a new
> CONFIG_INDIRECT_PIO for indirect-IO hosts/devices;
> - Added a new ACPI handler for indirect-IO hosts/devices;
> - Fixed the compile issues on V6;
>
> Changes from V6:
> - According to the comments from Bjorn and Alex, merge PCI IO and indirect-IO
> into a generic I/O space management, LIBIO;
> - Adopted the '_DEP' to replace the platform bus notifier. In this way, we can
> ensure the LPC peripherals' I/O resources had been translated to logical IO
> before the LPC peripheral enumeration;
> - Replaced the rwlock with rcu list based on Alex's suggestion;
> - Applied relaxed write/read to LPC driver;
> - Some bugs fixing and some optimazations based on the comments of V6;
>
> Changes from V5:
> - Made the extio driver more generic and locate in lib/;
> - Supported multiple indirect-IO bus instances;
> - Extended the pci_register_io_range() to support indirect-IO, then dropped
> the I/O reservation used in previous patchset;
> - Reimplemented the ACPI LPC support;
> - Fixed some bugs, including the compile error on other archs, the module
> building failure found by Ming Lei, etc;
>
> Changes from V4:
> - Some revises based on the comments from Bjorn, Rob on V4;
> - Fixed the compile error on some platforms, such as openrisc;
>
> Changes from V3:
> - UART support deferred to a separate patchset; This patchset only support
> ipmi device under LPC;
> - LPC bus I/O range is fixed to 0 ~ (PCIBIOS_MIN_IO - 1), which is separeted
> from PCI/PCIE PIO space;
> - Based on Arnd's remarks, removed the ranges property from Hip06 lpc dts and
> added a new fixup function, of_isa_indirect_io(), to get the I/O address
> directly from LPC dts configurations;
> - Support in(w,l)/out(w,l) for Hip06 lpc I/O;
> - Decouple the header file dependency on the gerenic io.h by defining in/out
> as normal functions in c file;
> - removed unused macro definitions in the LPC driver;
>
> Changes from V2:
> - Support the PIO retrieval from the linux PIO generated by
> pci_address_to_pio. This method replace the 4K PIO reservation in V2;
> - Support the flat-tree earlycon;
> - Some revises based on Arnd's remarks;
> - Make sure the linux PIO range allocated to Hip06 LPC peripherals starts
> from non-ZERO;
>
> Changes from V1:
> - Support the ACPI LPC device;
> - Optimize the dts LPC driver in ISA compatible mode;
> - Reserve the IO range below 4K in avoid the possible conflict with PCI host
> IO ranges;
> - Support the LPC uart and relevant earlycon;
>
> V7 thread here: https://lkml.org/lkml/2017/3/12/279
> v6 thread here: https://lkml.org/lkml/2017/1/24/25
> v5 thread here: https://lkml.org/lkml/2016/11/7/955
> v4 thread here: https://lkml.org/lkml/2016/10/20/149
> v3 thread here: https://lkml.org/lkml/2016/9/14/326
> v2 thread here: https://lkml.org/lkml/2016/9/7/356
> v1 thread here: https://lkml.org/lkml/2015/12/29/154
>
>
> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com>
> zhichang.yuan (6):
> LIBIO: Introduce a generic PIO mapping method
> PCI: Apply the new generic I/O management on PCI IO hosts
> OF: Add missing I/O range exception for indirect-IO devices
> LPC: Support the device-tree LPC host on Hip06/Hip07
> ACPI: Support the probing on the devices which apply indirect-IO
> LPC: Add the ACPI LPC support
>
> .../arm/hisilicon/hisilicon-low-pin-count.txt | 33 ++
> MAINTAINERS | 8 +
> arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 4 +
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 14 +
> arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 4 +
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 14 +
> drivers/acpi/Makefile | 1 +
> drivers/acpi/acpi_indirectio.c | 344 +++++++++++++
> drivers/acpi/internal.h | 5 +
> drivers/acpi/pci_root.c | 8 +-
> drivers/acpi/scan.c | 1 +
> drivers/bus/Kconfig | 9 +
> drivers/bus/Makefile | 1 +
> drivers/bus/hisi_lpc.c | 547 +++++++++++++++++++++
> drivers/of/address.c | 95 +++-
> drivers/pci/pci.c | 104 +---
> include/asm-generic/io.h | 50 ++
> include/linux/logic_pio.h | 174 +++++++
> include/linux/pci.h | 3 +-
> lib/Kconfig | 26 +
> lib/Makefile | 2 +
> lib/logic_pio.c | 413 ++++++++++++++++
> 22 files changed, 1758 insertions(+), 102 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> create mode 100644 drivers/acpi/acpi_indirectio.c
> create mode 100644 drivers/bus/hisi_lpc.c
> create mode 100644 include/linux/logic_pio.h
> create mode 100644 lib/logic_pio.c
Booted up on a D05, was able to use the LPC-connected IPMI interface.
Tested-by: dann frazier <dann.frazier@canonical.com>
^ permalink raw reply
* Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master (fwd)
From: Julia Lawall @ 2017-03-30 21:39 UTC (permalink / raw)
To: Christopher Bostic
Cc: joel-U3u1mxZcP9KHXe+LvDLADg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andrew-zrmu5oMJ5Fs, alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, Edward A . James,
Jeremy Kerr, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kbuild-all-JC7UmRfGjtg
Is master on line 514 allocated with kmalloc, or the devm call on line
522?
julia
---------- Forwarded message ----------
Date: Fri, 31 Mar 2017 00:15:09 +0800
From: kbuild test robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: kbuild-JC7UmRfGjtg@public.gmane.org
Cc: Julia Lawall <julia.lawall-L2FTfq7BK8M@public.gmane.org>
Subject: Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master
Hi Chris,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc4 next-20170330]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Christopher-Bostic/FSI-device-driver-implementation/20170330-184914
:::::: branch date: 5 hours ago
:::::: commit date: 5 hours ago
>> drivers/fsi/fsi-master-gpio.c:514:1-6: WARNING: invalid free of devm_ allocated data
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout f4bd3b6a41c7a59e9ce2e65947a4d3dfc2ee4a29
vim +514 drivers/fsi/fsi-master-gpio.c
f4bd3b6a Chris Bostic 2017-03-29 498 {
f4bd3b6a Chris Bostic 2017-03-29 499 struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
f4bd3b6a Chris Bostic 2017-03-29 500
f4bd3b6a Chris Bostic 2017-03-29 501 if (link != 0)
f4bd3b6a Chris Bostic 2017-03-29 502 return -ENODEV;
f4bd3b6a Chris Bostic 2017-03-29 503 if (master->gpio_enable)
f4bd3b6a Chris Bostic 2017-03-29 504 gpiod_set_value(master->gpio_enable, 1);
f4bd3b6a Chris Bostic 2017-03-29 505
f4bd3b6a Chris Bostic 2017-03-29 506 return 0;
f4bd3b6a Chris Bostic 2017-03-29 507 }
f4bd3b6a Chris Bostic 2017-03-29 508
f4bd3b6a Chris Bostic 2017-03-29 509 static void fsi_master_gpio_release(struct device *dev)
f4bd3b6a Chris Bostic 2017-03-29 510 {
f4bd3b6a Chris Bostic 2017-03-29 511 struct fsi_master_gpio *master = to_fsi_master_gpio(
f4bd3b6a Chris Bostic 2017-03-29 512 dev_to_fsi_master(dev));
f4bd3b6a Chris Bostic 2017-03-29 513
f4bd3b6a Chris Bostic 2017-03-29 @514 kfree(master);
f4bd3b6a Chris Bostic 2017-03-29 515 }
f4bd3b6a Chris Bostic 2017-03-29 516
f4bd3b6a Chris Bostic 2017-03-29 517 static int fsi_master_gpio_probe(struct platform_device *pdev)
f4bd3b6a Chris Bostic 2017-03-29 518 {
f4bd3b6a Chris Bostic 2017-03-29 519 struct fsi_master_gpio *master;
f4bd3b6a Chris Bostic 2017-03-29 520 struct gpio_desc *gpio;
f4bd3b6a Chris Bostic 2017-03-29 521
f4bd3b6a Chris Bostic 2017-03-29 522 master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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: [PATCHv5 06/11] s5p-cec.txt: document the HDMI controller phandle
From: Krzysztof Kozlowski @ 2017-03-30 21:37 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, Daniel Vetter, Russell King, dri-devel,
linux-samsung-soc, Inki Dae, Marek Szyprowski,
Javier Martinez Canillas, Benjamin Gaignard, Hans Verkuil,
devicetree
In-Reply-To: <20170329141543.32935-7-hverkuil@xs4all.nl>
On Wed, Mar 29, 2017 at 04:15:38PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Update the bindings documenting the new hdmi phandle.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> CC: linux-samsung-soc@vger.kernel.org
> CC: devicetree@vger.kernel.org
> CC: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCHv5 05/11] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
From: Krzysztof Kozlowski @ 2017-03-30 21:34 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, Daniel Vetter, Russell King, dri-devel,
linux-samsung-soc, Inki Dae, Marek Szyprowski,
Javier Martinez Canillas, Benjamin Gaignard, Hans Verkuil,
devicetree
In-Reply-To: <20170329141543.32935-6-hverkuil@xs4all.nl>
On Wed, Mar 29, 2017 at 04:15:37PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the
> s5p-cec driver to initialize the CEC notifier framework.
>
> Tested with my Odroid U3.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> CC: linux-samsung-soc@vger.kernel.org
> CC: devicetree@vger.kernel.org
> CC: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm/boot/dts/exynos4.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
Thanks, applied. Now I noticed that you need it for maintaining the
bisectability for this driver (although it is a staging driver). In that
case, if anyone needs this as well then:
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-hdmi-cec-4.12
for you to fetch changes up to 192c1df4a75499a6ab70aca38c6a7e5e40013d77:
ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi (2017-03-31 00:21:18 +0300)
----------------------------------------------------------------
Add to hdmi-cec node a phandle to hdmi node for new hdmi-cec notifier.
----------------------------------------------------------------
Hans Verkuil (1):
ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
arch/arm/boot/dts/exynos4.dtsi | 1 +
1 file changed, 1 insertion(+)
Best regards,
Krzysztof
^ permalink raw reply
* Applied "regulator: arizona-micsupp: Avoid potential memory leak reading init_data" to the regulator tree
From: Mark Brown @ 2017-03-30 21:23 UTC (permalink / raw)
To: Charles Keepax; +Cc: Mark Brown
In-Reply-To: <1490710484-25277-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
The patch
regulator: arizona-micsupp: Avoid potential memory leak reading init_data
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 2543ef3173889373fc07df61520e1bb42a99c85e Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Tue, 28 Mar 2017 15:14:37 +0100
Subject: [PATCH] regulator: arizona-micsupp: Avoid potential memory leak
reading init_data
The device argument passed to of_get_regulator_init_data is used to
do some devres memory allocation. Currently the driver passes the MFD
device pointer to this function, this could result in the init_data
allocation being leaked if the regulator is unbound but the MFD isn't.
Correct this issue by correctly passing the local platform device.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-micsupp.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c b/drivers/regulator/arizona-micsupp.c
index fcb98dbda837..0ed14e41de11 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -197,7 +197,8 @@ static const struct regulator_init_data arizona_micsupp_ext_default = {
.num_consumer_supplies = 1,
};
-static int arizona_micsupp_of_get_pdata(struct arizona *arizona,
+static int arizona_micsupp_of_get_pdata(struct device *dev,
+ struct arizona *arizona,
struct regulator_config *config,
const struct regulator_desc *desc)
{
@@ -211,7 +212,7 @@ static int arizona_micsupp_of_get_pdata(struct arizona *arizona,
if (np) {
config->of_node = np;
- init_data = of_get_regulator_init_data(arizona->dev, np, desc);
+ init_data = of_get_regulator_init_data(dev, np, desc);
if (init_data) {
init_data->consumer_supplies = &micsupp->supply;
@@ -266,8 +267,8 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_micsupp_of_get_pdata(arizona, &config,
- desc);
+ ret = arizona_micsupp_of_get_pdata(&pdev->dev, arizona,
+ &config, desc);
if (ret < 0)
return ret;
}
--
2.11.0
^ permalink raw reply related
* Applied "regulator: arizona-ldo1: Avoid potential memory leak reading init_data" to the regulator tree
From: Mark Brown @ 2017-03-30 21:23 UTC (permalink / raw)
To: Charles Keepax; +Cc: Mark Brown
In-Reply-To: <1490710484-25277-2-git-send-email-ckeepax@opensource.wolfsonmicro.com>
The patch
regulator: arizona-ldo1: Avoid potential memory leak reading init_data
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0feb837a42c95fee901e03f76a1266db85ceb6ec Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Tue, 28 Mar 2017 15:14:38 +0100
Subject: [PATCH] regulator: arizona-ldo1: Avoid potential memory leak reading
init_data
The device argument passed to of_get_regulator_init_data is used to
do some devres memory allocation. Currently the driver passes the MFD
device pointer to this function, this could result in the init_data
allocation being leaked if the regulator is unbound but the MFD isn't.
Correct this issue by correctly passing the local platform device.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-ldo1.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index 302b57cb89c6..cf558168664d 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -186,7 +186,8 @@ static const struct regulator_init_data arizona_ldo1_wm5110 = {
.num_consumer_supplies = 1,
};
-static int arizona_ldo1_of_get_pdata(struct arizona *arizona,
+static int arizona_ldo1_of_get_pdata(struct device *dev,
+ struct arizona *arizona,
struct regulator_config *config,
const struct regulator_desc *desc)
{
@@ -212,8 +213,7 @@ static int arizona_ldo1_of_get_pdata(struct arizona *arizona,
if (init_node) {
config->of_node = init_node;
- init_data = of_get_regulator_init_data(arizona->dev, init_node,
- desc);
+ init_data = of_get_regulator_init_data(dev, init_node, desc);
if (init_data) {
init_data->consumer_supplies = &ldo1->supply;
@@ -283,7 +283,8 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_ldo1_of_get_pdata(arizona, &config, desc);
+ ret = arizona_ldo1_of_get_pdata(&pdev->dev, arizona,
+ &config, desc);
if (ret < 0)
return ret;
}
--
2.11.0
^ permalink raw reply related
* Applied "MAINTAINERS: Add missing regulator regex for Wolfson Arizona parts" to the regulator tree
From: Mark Brown @ 2017-03-30 21:23 UTC (permalink / raw)
To: Charles Keepax; +Cc: Mark Brown
In-Reply-To: <1490710484-25277-3-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
The patch
MAINTAINERS: Add missing regulator regex for Wolfson Arizona parts
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From cdf4275e957c6bad3756e98942341667f1d7de7d Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Date: Tue, 28 Mar 2017 15:14:39 +0100
Subject: [PATCH] MAINTAINERS: Add missing regulator regex for Wolfson Arizona
parts
The maintainers entry for the Wolfson parts seems to be missing
an entry that covers the Arizona regulator drivers, correct this by
adding one.
Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9bf5aa617cf2..ef0c801aff45 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13119,6 +13119,7 @@ F: drivers/mfd/cs47l24*
F: drivers/power/supply/wm83*.c
F: drivers/rtc/rtc-wm83*.c
F: drivers/regulator/wm8*.c
+F: drivers/regulator/arizona*
F: drivers/video/backlight/wm83*_bl.c
F: drivers/watchdog/wm83*_wdt.c
F: include/linux/mfd/arizona/
--
2.11.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] ARM: dts: r7s72100: fix ethernet clock parent
From: Chris Brandt @ 2017-03-30 21:16 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Mark Rutland, Geert Uytterhoeven
Cc: devicetree, linux-renesas-soc, Chris Brandt
Technically, the Ethernet block is run off the 133MHz Bus (B) clock, not
the 33MHz Peripheral 0 (P0) clock.
Fixes: 969244f9c720 ("ARM: dts: r7s72100: add ethernet clock to device tree")
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
arch/arm/boot/dts/r7s72100.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 34994afa9d15..c199c4eea73e 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -121,7 +121,7 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0xfcfe0430 4>;
- clocks = <&p0_clk>;
+ clocks = <&b_clk>;
clock-indices = <R7S72100_CLK_ETHER>;
clock-output-names = "ether";
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master
From: Benjamin Herrenschmidt @ 2017-03-30 20:50 UTC (permalink / raw)
To: Christopher Bostic, Joel Stanley
Cc: Mark Rutland, devicetree, Andrew Jeffery, Greg KH, Russell King,
rostedt, Linux Kernel Mailing List, Rob Herring, Jeremy Kerr,
Edward A . James, Alistair Popple, mingo, linux-arm-kernel
In-Reply-To: <0e1bcf3a-e8d7-9f50-bdf7-2a1e7466665b@linux.vnet.ibm.com>
On Thu, 2017-03-30 at 13:15 -0500, Christopher Bostic wrote:
> > > +static void serial_in(struct fsi_master_gpio *master, struct fsi_gpio_msg *msg,
> > > + uint8_t num_bits)
> > > +{
> > > + uint8_t bit, in_bit;
> > > +
> > > + set_sda_input(master);
> > > +
> > > + for (bit = 0; bit < num_bits; bit++) {
> > > + clock_toggle(master, 1);
> > > + in_bit = sda_in(master);
> > > + msg->msg <<= 1;
> > > + msg->msg |= ~in_bit & 0x1; /* Data is negative active */
> > > + }
> > > + msg->bits += num_bi ts;
> > > +}
> > > +
> > > +static void serial_out(struct fsi_master_gpio *master,
> > > + const struct fsi_gpio_msg *cmd)
> > > +{
> > > + uint8_t bit;
> > > + uint64_t msg = ~cmd->msg; /* Data is negative active */
> > > + uint64_t sda_mask = 0x1ULL << (cmd->bits - 1);
> > > + uint64_t last_bit = ~0;
> > > + int next_bit;
> > > +
> > > + if (!cmd->bits) {
> > > + dev_warn(master->dev, "trying to output 0 bits\n");
> > > + return;
> > > + }
> > > + set_sda_output(master, 0);
> > > +
> > > + /* Send the start bit */
> > > + sda_out(master, 0);
> > > + clock_toggle(master, 1);
> > > +
> > > + /* Send the message */
> > > + for (bit = 0; bit < cmd->bits; bit++) {
> > > + next_bit = (msg & sda_mask) >> (cmd->bits - 1);
> > > + if (last_bit ^ next_bit) {
> > > + sda_out(master, next_bit);
> > > + last_bit = next_bit;
> > > + }
> > > + clock_toggle(master, 1);
> > > + msg <<= 1;
> > > + }
> > > +}
As I mentioned privately, I don't think this is right, unless your
clock signal is inverted or my protocol spec is wrong...
Your clock toggle is written so you call it right after the rising
edge. It does delay, 0, delay, 1.
But according to the FSI timing diagram I have, you need to establish
the data around the falling edge, it gets sampled by the slave on the
rising edge. So as it is, your code risks violating the slave hold
time.
On input, you need to sample on the falling edge, right before it. You
are sampling after the rising edge, so you aren't leaving enough time
for the slave to establish the data.
You could probably just flip clock_toggle() around. Make it: 0, delay,
1, delay.
That way you can do for sends: sda_out + toggle, and for receive
toggle + sda_in. That will make you establish your output data and
sample right before the falling edge, which should be ok provided the
diagram I have is right.
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO
From: Rafael J. Wysocki @ 2017-03-30 20:31 UTC (permalink / raw)
To: zhichang.yuan
Cc: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rafael-DgEjT+Ai2ygdnm+yROfE0A,
arnd-r2nGTMty4D4,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, brian.starkey-5wv7dgnIgG8,
olof-nZhT3qVonbNeoWH0uzbU5w, lorenzo.pieralisi-5wv7dgnIgG8,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, minyard-HInyCGIudOg,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w, kantyzc-9Onoh4P/yGk,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q
In-Reply-To: <1490887619-61732-6-git-send-email-yuanzhichang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
On Thursday, March 30, 2017 11:26:58 PM zhichang.yuan wrote:
> On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O
> with some special host-local I/O ports known on x86. To access the I/O
> peripherals, an indirect-IO mechanism is introduced to mapped the host-local
> I/O to system logical/fake PIO similar the PCI MMIO on architectures where no
> separate I/O space exists. Just as PCI MMIO, the host I/O range should be
> registered before probing the downstream devices and set up the I/O mapping.
> But current ACPI bus probing doesn't support these indirect-IO hosts/devices.
>
> This patch introdueces a new ACPI handler for this device category. Through the
> handler attach callback, the indirect-IO hosts I/O registration is done and
> all peripherals' I/O resources are translated into logic/fake PIO before
> starting the enumeration.
Can you explain to me briefly what exactly this code is expected to be doing?
Thanks,
Rafael
--
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] ASoC: wm8903: add regulator handling
From: Stephen Warren @ 2017-03-30 19:42 UTC (permalink / raw)
To: Linus Walleij, Liam Girdwood, Mark Brown
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Charles Keepax
In-Reply-To: <20170320091352.4115-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 03/20/2017 03:13 AM, Linus Walleij wrote:
> The WM8903 has four different voltage inputs: AVDD, CPVDD, DBVDD
> and DCVDD. On the Qualcomm APQ8060 Dragonboard these are all
> supplied from proper regulators and thus need activating and
> binding.
>
> This is a quick-and-dirty solution just grabbing and enabling the
> regulator supplies on probe() and disabling them on remove() and
> the errorpath. More elaborate power management is likely possible.
>
> I assume the nVidia designs using this codec have some hard-wired
> always-on power and will be happy with using the dummy regulators
> for this. But someone from the nVidia camp should probably check
> whether they can bind these to proper regulators instead.
>
> We also amend the DT binding document. A small change like this
> does not warrant a separate patch for augmenting these.
Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Sorry for the slow response.
Tested using NVIDIA springbank/seaboard board. Just in case anyone reads
this later and wonders how: I will point out that in the baseline
v4.11-rc4, the LCD (or perhaps just its backlight) doesn't work on this
HW any more, but since the GUI login prompt plays a sound, I was still
able to validate the WM8903 change.
--
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: [v5 2/4] dt-bindings: mmc: add description of PHY delays for sdhci-cadence
From: Ulf Hansson @ 2017-03-30 19:31 UTC (permalink / raw)
To: Piotr Sroka
Cc: linux-mmc@vger.kernel.org, Adrian Hunter,
linux-kernel@vger.kernel.org, Masahiro Yamada, Rob Herring,
Mark Rutland, devicetree@vger.kernel.org
In-Reply-To: <1490106781-3129-1-git-send-email-piotrs@cadence.com>
On 21 March 2017 at 15:33, Piotr Sroka <piotrs@cadence.com> wrote:
> DTS properties are used instead of fixed data
> because PHY settings can be different for different chips/boards.
> Add description of new DLL PHY delays.
>
> Signed-off-by: Piotr Sroka <piotrs@cadence.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> Changes for v2:
> - file was created in v2. It was a part of driver source file patch.
> - most delays were moved from dts file
> to data associated with an SoC specific compatible
> - description of delays was updated to be more clearly
> ---
> Changes for v3:
> - move all delays back to dts because they are also boards dependent
> - prefix all of the Cadence-specific properties with cdns prefix
> ---
> Changes for v4:
> - change the beginning of the commit subject
> ---
> Changes for v5:
> - change name of property to be consistent with timing modes
> available in Linux
> ---
> .../devicetree/bindings/mmc/sdhci-cadence.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> index c0f37cb..fa423c2 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> @@ -19,6 +19,53 @@ if supported. See mmc.txt for details.
> - mmc-hs400-1_8v
> - mmc-hs400-1_2v
>
> +Some PHY delays can be configured by following properties.
> +PHY DLL input delays:
> +They are used to delay the data valid window, and align the window
> +to sampling clock. The delay starts from 5ns (for delay parameter equal to 0)
> +and it is increased by 2.5ns in each step.
> +- cdns,phy-input-delay-sd-highspeed:
> + Value of the delay in the input path for SD high-speed timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-legacy:
> + Value of the delay in the input path for legacy timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-sd-uhs-sdr12:
> + Value of the delay in the input path for SD UHS SDR12 timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-sd-uhs-sdr25:
> + Value of the delay in the input path for SD UHS SDR25 timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-sd-uhs-sdr50:
> + Value of the delay in the input path for SD UHS SDR50 timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-sd-uhs-ddr50:
> + Value of the delay in the input path for SD UHS DDR50 timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-mmc-highspeed:
> + Value of the delay in the input path for MMC high-speed timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-mmc-ddr:
> + Value of the delay in the input path for eMMC high-speed DDR timing
> + Valid range = [0:0x1F].
> +
> +PHY DLL clock delays:
> +Each delay property represents the fraction of the clock period.
> +The approximate delay value will be
> +(<delay property value>/128)*sdmclk_clock_period.
> +- cdns,phy-dll-delay-sdclk:
> + Value of the delay introduced on the sdclk output
> + for all modes except HS200, HS400 and HS400_ES.
> + Valid range = [0:0x7F].
> +- cdns,phy-dll-delay-sdclk-hsmmc:
> + Value of the delay introduced on the sdclk output
> + for HS200, HS400 and HS400_ES speed modes.
> + Valid range = [0:0x7F].
> +- cdns,phy-dll-delay-strobe:
> + Value of the delay introduced on the dat_strobe input
> + used in HS400 / HS400_ES speed modes.
> + Valid range = [0:0x7F].
> +
> Example:
> emmc: sdhci@5a000000 {
> compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
> @@ -29,4 +76,5 @@ Example:
> mmc-ddr-1_8v;
> mmc-hs200-1_8v;
> mmc-hs400-1_8v;
> + cdns,phy-dll-delay-sdclk = <0>;
> };
> --
> 2.2.2
>
^ permalink raw reply
* Re: [PATCH v3 0/6] bus: brcmstb_gisb: add support for GISBv7 arbiter
From: Florian Fainelli @ 2017-03-30 19:29 UTC (permalink / raw)
To: Mark Rutland, Florian Fainelli
Cc: Doug Berger, robh+dt, computersforpeace, gregory.0xf0,
bcm-kernel-feedback-list, linus.walleij, treding, jonathanh, olof,
mirza.krak, suzuki.poulose, bgolaszewski, devicetree,
linux-kernel, linux-arm-kernel, catalin.marinas, will.deacon
In-Reply-To: <20170330181932.GB8062@leverpostej>
On 03/30/2017 11:19 AM, Mark Rutland wrote:
> On Thu, Mar 30, 2017 at 09:33:32AM -0700, Florian Fainelli wrote:
>> On 03/29/2017 05:29 PM, Doug Berger wrote:
>>> This patch set contains changes to enable the GISB arbiter driver
>>> on the latest ARM64 architecture Set-Top Box chips from Broadcom.
>>>
>>> Since the ARM64 architecture does not support the hooking of low
>>> level fault handlers the driver has been adjusted to depend solely
>>> on GISB interrupts and notify events to provide diagnostic
>>> messaging. The GISB hardware still triggers bus faults for the
>>> processor so the default low-level aborts will occur and will be
>>> handled based on the architecture specific kernel implementation.
>>>
>>> While this tends to obsure the GISB error messaging it is still
>>> reasonable so the same approach is applied to the ARM architecture
>>> for consistency.
>>>
>>> The patches also correct some issues with the existing driver
>>> and add the new register map for the GISBv7 hardware first
>>> appearing in the BCM7278 device.
>>
>> This all looks great to me, and since there are no more ARM64
>> dependencies I can take this via the Broadcom ARM/ARM64 SoC pull requests.
>>
>> Mark, are you also happy with this v3?
>
> It looks fine by me.
Series applied to drivers/next, thanks everyone!
--
Florian
^ permalink raw reply
* Re: [PATCH V11 6/6] thermal: bcm2835: add thermal driver for bcm2835 SoC
From: Stefan Wahren @ 2017-03-30 19:11 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Frank Rowand, kernel, Eric Anholt, Zhang Rui, Rob Herring,
Florian Fainelli, linux-rpi-kernel, linux-pm, devicetree
In-Reply-To: <20170330045725.GA12995@localhost.localdomain>
Hi Eduardo,
> Eduardo Valentin <edubezval@gmail.com> hat am 30. März 2017 um 06:57 geschrieben:
>
>
> On Tue, Mar 28, 2017 at 09:58:09PM -0700, Eduardo Valentin wrote:
> > On Sun, Mar 12, 2017 at 10:11:05PM +0000, Stefan Wahren wrote:
> > > Add basic thermal driver for bcm2835 SoC.
> > >
> > > This driver currently make sure that tsense HW block is set up
> > > correctly.
> > >
> > > Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
> > > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > > Acked-by: Eric Anholt <eric@anholt.net>
> >
> > I see no issue with this driver at this point.
> >
> > As I mentioned, the full series needs to go together. You either get an
> > Ack from OF maintainers, and I take the series, or you can add my
> >
> > Acked-by: Eduardo Valentin <edubezval@gmail.com>
> >
> > after fixing the small comment from Nobuhiro.
> >
>
> Based on other drivers that require negative values, I assume patches 1
> and 2 of these series are needed, but more for enforcing the API, given
> that the current of-thermal driver still retrieves the negative values
> from DTB [1].
>
> A third option on top of what I suggested above is to split the series.
> Given that you could still get the proper coefficients
> with current of-thermal, I would suggest you to split this series into
> two (patches 1-2, 3-6) in your next version, so we avoid futher delays
> on the driver, while patches 1-2 waits for acks from OF side.
i revert patches #1, #2 and the slope value was still correct. So i will choose the third option and split the series.
Thanks
Stefan
>
> [1] - https://patchwork.kernel.org/patch/9612613/
^ permalink raw reply
* Re: [PATCH v7 00/13] mmc: Add support to Marvell Xenon SD Host Controller
From: Russell King - ARM Linux @ 2017-03-30 18:56 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Ulf Hansson, Adrian Hunter, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Jimmy Xu, Andrew Lunn, Mike Turquette, Nadav Haklai, Ziji Hu,
Victor Gu, Doug Jones, linux-clk-u79uwXL29TY76Z2rM5mHXA,
Jisheng Zhang, Yehuda Yitschak, Marcin Wojtas, Kostya Porotchkin,
Hanna Hawa, Sebastian Hesselbarth,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Rob Herring,
Ryan Gao, Wei(SOCP) Liu
In-Reply-To: <cover.51071caa64e5df81264a91b9a81ed1e94f47d2c4.1490886907.git-series.gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Thu, Mar 30, 2017 at 05:22:52PM +0200, Gregory CLEMENT wrote:
> - Remove parse of child node mmc-card. Wait for a better solution.
So for mcbin, I have:
&ap_sdhci0 {
bus-width = <8>;
marvell,xenon-emmc;
marvell,xenon-phy-type = "emmc 5.1 phy";
/*
* Not stable in HS modes - phy needs "more calibration", so add
* the "slow-mode" and disable SDR104, SDR50 and DDR50 modes.
*/
marvell,xenon-phy-slow-mode;
no-1-8-v;
non-removable;
status = "okay";
vqmmc-supply = <&v_vddo_h>;
#address-cells = <1>;
#size-cells = <0>;
mmccard: mmccard@0 {
compatible = "mmc-card";
reg = <0>;
};
};
Does this mean the "mmccard" bit is no longer required - or is it required
for the eMMC to be detected but is no longer supported by the driver?
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 2/3] usb: add DT bindings for farady fotg2 host controller
From: Hans Ulli Kroll @ 2017-03-30 18:31 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Hans Ulli Kroll, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, Linux USB List, Greg Kroah-Hartman,
Mark Rutland
In-Reply-To: <CACRpkdbjNS+ADawDCub5OP1iguNk+4Ked+mh_T_-bJ=6-9-3Nw@mail.gmail.com>
Hi Linus,
On Thu, 30 Mar 2017, Linus Walleij wrote:
> On Tue, Feb 21, 2017 at 3:43 PM, Rob Herring <robh@kernel.org> wrote:
> > On Fri, Feb 17, 2017 at 4:07 AM, Hans Ulli Kroll
> > <ulli.kroll@googlemail.com> wrote:
> >> Hi Rob,
> >>
> >> On Wed, 15 Feb 2017, Rob Herring wrote:
> >>
> >>> On Wed, Feb 08, 2017 at 09:00:09PM +0100, Hans Ulli Kroll wrote:
> >>> > This adds DT bindings for the Faraday FOTG2 host controller.
> >>> >
> >>> > Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
> >>> > ---
> >>> > Documentation/devicetree/bindings/usb/fotg2-host.txt | 15 +++++++++++++++
> >>> > 1 file changed, 15 insertions(+)
> >>> > create mode 100644 Documentation/devicetree/bindings/usb/fotg2-host.txt
> >>> >
> >>> > diff --git a/Documentation/devicetree/bindings/usb/fotg2-host.txt b/Documentation/devicetree/bindings/usb/fotg2-host.txt
> >>> > new file mode 100644
> >>> > index 000000000000..4c07566a4bf5
> >>> > --- /dev/null
> >>> > +++ b/Documentation/devicetree/bindings/usb/fotg2-host.txt
> >>> > @@ -0,0 +1,15 @@
> >>> > +Faraday FOTG Host controller
> >>> > +
> >>> > +Required properties:
> >>> > +
> >>> > +- compatible: should be "faraday,fotg210-hcd"
> >>>
> >>> hcd as in "host controller driver"? Bindings describe h/w not drivers.
> >>>
> >>> It's an OTG controller or host controller?
> >>>
> >>
> >> here only the host controller part used.
> >>
> >> faraday fotg2 is a dual role hcd/otg device and here is only the
> >> host part used.
> >
> > Because you don't care about device mode or restricted by the IP
> > configuration or SoC integration? The former is a user choice and
> > shouldn't be part of DT. The latter should be implied by an SoC
> > specific compatible string. Using only a compatible string for a
> > licensed IP is not specific enough as vendors use differing versions
> > and integrate them in different ways.
>
> Hans can you add:
>
> compatible = "cortina,gemini-fotg", "faraday,fotg210-hcd" or something
> as composite compatible for our controller?
>
I prefer
"faraday,fotg210-usb2"
I've got rejected by Rob due the fact this is an dual role controller,
which supports both host and device mode. And DT must reflect this desgn
pattern.
Currently I'm wrappingt my head around the design of the fsl-mph-dr-of.c
driver to use this as a blueprint for the Faraday driver.
Greetings
Hans Ulli Kroll
^ permalink raw reply
* Re: [PATCHv3] iio: adc: cpcap: Add minimal support for CPCAP PMIC ADC
From: Jonathan Cameron @ 2017-03-30 18:26 UTC (permalink / raw)
To: Rob Herring, Tony Lindgren
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Michael Scott,
Sebastian Reichel
In-Reply-To: <20170329212637.syluvxy5cp2qub3h@rob-hp-laptop>
On 29/03/17 22:26, Rob Herring wrote:
> On Thu, Mar 23, 2017 at 08:38:42PM -0700, Tony Lindgren wrote:
>> On Motorola phones like droid 4 there is a custom CPCAP PMIC. This PMIC
>> has ADCs that are used for battery charging and USB PHY VBUS and ID pin
>> detection.
>>
>> Unfortunately the only documentation for this ADC seems to be the
>> Motorola mapphone Linux kernel tree. I have tested that reading raw and
>> scaled values works, but I have not used the timed sampling that the ADC
>> seems to support.
>>
>> Let's add a minimal support for it so we can eventually provide IIO
>> channels for the related battery charging and USB PHY drivers.
>>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: Marcel Partap <mpartap-hi6Y0CQ0nG0@public.gmane.org>
>> Cc: Michael Scott <michael.scott-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>> ---
>>
>> Changes since v2:
>>
>> - Simplify things further by using channel based indexing and
>> remove more drivers specific enumerations
>>
>> Changes since v1:
>>
>> - Fix numerous issues pointed out by Peter Meerwald-Stadler
>> <pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org> and Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> - Simplify things further by limiting read functions to a
>> single channel instead of a bank and got rid of the driver
>> specific cpcap_adc_conv_type in favor of IIO generic types
>>
>> ---
>> .../devicetree/bindings/iio/adc/cpcap-adc.txt | 18 +
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Been long enough now that I'm happy to take this.
Thanks for looking at the bindings Rob!
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Jonathan
>
>> drivers/iio/adc/Kconfig | 11 +
>> drivers/iio/adc/Makefile | 1 +
>> drivers/iio/adc/cpcap-adc.c | 1007 ++++++++++++++++++++
>> 4 files changed, 1037 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/adc/cpcap-adc.txt
>> create mode 100644 drivers/iio/adc/cpcap-adc.c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox