Re: [PATCH v5 10/12] gpio: Support for unified device properties interface

[Alexandre Courbot]

On Sat, Oct 18, 2014 at 6:47 PM, Arnd Bergmann  wrote:
> On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
>> On October 17, 2014 2:16:00 PM CEST, "Rafael J. Wysocki" 
>>  wrote:
>> >From: Mika Westerberg 
>> >
>> >Some drivers need to deal with only firmware representation of its
>> >GPIOs. An example would be a GPIO button array driver where each button
>> >is described as a separate firmware node in device tree. Typically
>> >these
>> >child nodes do not have physical representation in the Linux device
>> >model.
>> >
>> >In order to help device drivers to handle such firmware child nodes we
>> >add dev[m]_get_named_gpiod_from_child() that takes a child firmware
>> >node pointer as its second argument (the first one is the parent device
>> >itself), finds the GPIO using whatever is the underlying firmware
>> >method, and requests the GPIO properly.
>>
>> Could we also have a wrapper around this function without a "name" argument,
>> using just the index?
>
> Expanding on this thought: I think we should mandate for new bindings
> that they use either a name and no index, or an index but not name,

I'm afraid this could forbid some useful use-cases, namely the ones
where several GPIOs serve the same function (and are typically set
together). We had a few patch proposals to handle such GPIO groups,
and even though one was in pretty good shape the submitter did not
push it until the end. :/

But my concern is that instead of having this:

enable-gpio = <&gpio 0 GPIO_ACTIVE_HIGH>;
value-gpios = <&gpio 1 GPIO_ACTIVE_HIGH ... &gpio 8 GPIO_ACTIVE_HIGH>;

We would force this:

enable-gpio = <&gpio 0 GPIO_ACTIVE_HIGH>;
value0-gpio = <&gpio 1 GPIO_ACTIVE_HIGH>;
...
value7-gpio = <&gpio 8 GPIO_ACTIVE_HIGH>;

Or this:

// First GPIO is enable, other GPIOs are value
gpios = <&gpio 0 GPIO_ACTIVE_HIGH &gpio 1 GPIO_ACTIVE_HIGH ... &gpio 8
GPIO_ACTIVE_HIGH>;

Most bindings don't need that much sophistication, and for these we
should indeed make sure that they stick to using either the names or
index (and in a consistent manner), but closing the possibility to use
both together may bite us in the end.


> and I also think that for named gpios, we should try to converge on a
> common naming scheme. As discussed, we will probably want to support all
> the existing ways to do this even with ACPI and with the unified
> interface, but it doesn't have to be the obvious way.

Personally, I like the idea that each GPIO has a function, so now that
ACPI fully supports this I'd suggest the policy of using names for
each GPIO (e.g. never use the fallback "gpios" or "gpio" property),
and only ressort to indexes if several GPIOs happen to serve the same
function. I know we haven't reached consensus about this so far, but
it would be nice it we could discuss this point again in the light of
the new ACPI capabilities and come with something to write as a
guideline in the GPIO documentation.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESUBMIT PATCH v4 7/8] regulator: sky81452: Add compatible string for device binding

[Gyungoh Yoo]

On Fri, Oct 17, 2014 at 04:26:05PM +0200, Mark Brown wrote:
> On Fri, Oct 17, 2014 at 07:43:09PM +0900, Gyungoh Yoo wrote:
> 
> > Are you talking about simplification using of_regulator_match()?
> > This driver has only one regulator.
> > Is the API also useful for this driver?
> 
> The thing I'm seeing is that the binding for your device with the
> subnode looks very much like the device trees of devices with multiple
> regulators.  The fact that you only have one regulator is a bit
> difference but not that much.  It seems like drivers should fit into one
> of two patterns: either the regulator is described in the root node for
> the device for single purpose devices or there should be a collection of
> regulators like is supported with this helper API.  Having a collection
> with only one node doesn't seem to be a problem in any way.
> 
> > Like reg-fixed-voltage, how about using of_get_fixed_voltage_config()?
> 
> The driver doesn't seem to need any property parsing of its own so it
> shoudn't need anything beyond basic calls into the core.

Thank you for your kind comments.
My understanding is getting better.

For my clear understanding:
I think the original designed which I wanted to design is similar
with arizona-ldo1.c
It seems that this is 1st pattern your explained above.
Can I ask what is different between arizona-ldo1.c and
this sky81452-regulator.c?
I think both are designed under root node.

Thank you.

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

[PATCH v4 2/3] ARM: mediatek: add dts for mt6592-evb

[Howard Chen]

The mt6592-evb is an evaluation board based on the MT6592 SoC.

Signed-off-by: Howard Chen 
---
 arch/arm/boot/dts/Makefile   |  3 ++-
 arch/arm/boot/dts/mt6592-evb.dts | 45 
 2 files changed, 47 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/mt6592-evb.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8f12390..947f0d5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -514,7 +514,8 @@ dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \
dove-d2plug.dtb \
dove-d3plug.dtb \
dove-dove-db.dtb
-dtb-$(CONFIG_ARCH_MEDIATEK) += mt6589-aquaris5.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6589-aquaris5.dtb \
+   mt6592-evb.dtb
 
 targets += dtbs dtbs_install
 targets += $(dtb-y)
diff --git a/arch/arm/boot/dts/mt6592-evb.dts b/arch/arm/boot/dts/mt6592-evb.dts
new file mode 100644
index 000..be74a38
--- /dev/null
+++ b/arch/arm/boot/dts/mt6592-evb.dts
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Howard Chen 
+ *
+ * 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.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "mt6592.dtsi"
+
+/ {
+   model = "mt6592 evb";
+   compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
+
+   chosen {
+   bootargs = "console=ttyS0,921600n8";
+   };
+
+   memory {
+   reg = <0x8000 0x0800>;
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&uart1 {
+   status = "okay";
+};
+
+&uart2 {
+   status = "okay";
+};
+
+&uart3 {
+   status = "okay";
+};
-- 
1.9.1

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

[PATCH v4 3/3] dt-bindings: add documentation for Mediatek SoC

[Howard Chen]

This adds a DT binding documentation for the MT6592 SoC from Mediatek.

Signed-off-by: Howard Chen 
---
 Documentation/devicetree/bindings/arm/mediatek.txt| 7 +--
 Documentation/devicetree/bindings/serial/mtk-uart.txt | 3 ++-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index fa25226..1d2d151 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -1,10 +1,10 @@
 Mediatek MT6589 Platforms Device Tree Bindings
 
-Boards with a SoC of the Mediatek MT6589 shall have the following property:
+Boards with a SoC from Mediatek shall have the following property:
 
 Required root node property:
 
-compatible: must contain "mediatek,mt6589"
+compatible: must contain one of "mediatek,mt6589", "mediatek,mt6592"
 
 
 Supported boards:
@@ -12,3 +12,6 @@ Supported boards:
 - bq Aquaris5 smart phone:
 Required root node properties:
   - compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
+
+- Evaluation board for MT6592:
+  - compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt 
b/Documentation/devicetree/bindings/serial/mtk-uart.txt
index 48358a3..e2864b7 100644
--- a/Documentation/devicetree/bindings/serial/mtk-uart.txt
+++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt
@@ -2,9 +2,10 @@
 
 Required properties:
 - compatible should contain:
+  * "mediatek,mt6592-uart" for MT6592 compatible UARTS
   * "mediatek,mt6589-uart" for MT6589 compatible UARTS
   * "mediatek,mt6582-uart" for MT6582 compatible UARTS
-  * "mediatek,mt6577-uart" for all compatible UARTS (MT6589, MT6582, MT6577)
+  * "mediatek,mt6577-uart" for all compatible UARTS on MT65xx
 
 - reg: The base address of the UART register bank.
 
-- 
1.9.1

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

[PATCH v4 1/3] ARM: mediatek: Add basic support for mt6592

[Howard Chen]

* A dtsi for boards based on Mediatek MT6592 SoCs
* Compatible string in arch/arm/mach-mediatek/mediatek.c

Signed-off-by: Howard Chen 
---
 arch/arm/boot/dts/mt6592.dtsi | 138 ++
 arch/arm/mach-mediatek/mediatek.c |   1 +
 2 files changed, 139 insertions(+)
 create mode 100644 arch/arm/boot/dts/mt6592.dtsi

diff --git a/arch/arm/boot/dts/mt6592.dtsi b/arch/arm/boot/dts/mt6592.dtsi
new file mode 100644
index 000..367ba8f
--- /dev/null
+++ b/arch/arm/boot/dts/mt6592.dtsi
@@ -0,0 +1,138 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Howard Chen 
+ *
+ * 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.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include "skeleton.dtsi"
+
+/ {
+   compatible = "mediatek,mt6592";
+   interrupt-parent = <&gic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   };
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   };
+   cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x2>;
+   };
+   cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x3>;
+   };
+   cpu@4 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x4>;
+   };
+   cpu@5 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x5>;
+   };
+   cpu@6 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x6>;
+   };
+   cpu@7 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x7>;
+   };
+   };
+
+   system_clk: dummy13m {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+
+   rtc_clk: dummy32k {
+   compatible = "fixed-clock";
+   clock-frequency = <32000>;
+   #clock-cells = <0>;
+   };
+
+   uart_clk: uart_clk {
+   compatible = "fixed-clock";
+   clock-frequency = <2600>;
+   #clock-cells = <0>;
+   };
+
+   timer: timer@10008000 {
+   compatible = "mediatek,mt6577-timer";
+   reg = <0x10008000 0x80>;
+   interrupts = ;
+   clocks = <&system_clk>, <&rtc_clk>;
+   clock-names = "system-clk", "rtc-clk";
+   };
+
+   gic: interrupt-controller@10211000 {
+   compatible = "arm,cortex-a9-gic";
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   reg = <0x10211000 0x1000>,
+ <0x10212000 0x1000>;
+   };
+
+   uart0: serial@11002000 {
+   compatible = "mediatek,mt6592-uart", "mediatek,mt6577-uart";
+   reg = <0x11002000 0x400>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   status = "disabled";
+   };
+
+   uart1: serial@11003000 {
+   compatible = "mediatek,mt6592-uart", "mediatek,mt6577-uart";
+   reg = <0x11003000 0x400>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   status = "disabled";
+   };
+
+   uart2: serial@11004000 {
+   compatible = "mediatek,mt6592-uart", "mediatek,mt6577-uart";
+   reg = <0x11004000 0x400>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   status = "disabled";
+   };
+
+   uart3: serial@11005000 {
+   compatible = "mediatek,mt6592-uart", "mediatek,mt6577-uart";
+   reg = <0x11005000 0x400>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   status = "disabled";
+   };
+};

Re: [PATCH v5 10/12] gpio: Support for unified device properties interface

[Rafael J. Wysocki]

On Saturday, October 18, 2014 11:47:41 AM Arnd Bergmann wrote:
> On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
> > On October 17, 2014 2:16:00 PM CEST, "Rafael J. Wysocki" 
> >  wrote:
> > >From: Mika Westerberg 
> > >
> > >Some drivers need to deal with only firmware representation of its
> > >GPIOs. An example would be a GPIO button array driver where each button
> > >is described as a separate firmware node in device tree. Typically
> > >these
> > >child nodes do not have physical representation in the Linux device
> > >model.
> > >
> > >In order to help device drivers to handle such firmware child nodes we
> > >add dev[m]_get_named_gpiod_from_child() that takes a child firmware
> > >node pointer as its second argument (the first one is the parent device
> > >itself), finds the GPIO using whatever is the underlying firmware
> > >method, and requests the GPIO properly.
> > 
> > Could we also have a wrapper around this function without a "name" argument,
> > using just the index?
> 
> Expanding on this thought: I think we should mandate for new bindings
> that they use either a name and no index, or an index but not name,
> and I also think that for named gpios, we should try to converge on a
> common naming scheme. As discussed, we will probably want to support all
> the existing ways to do this even with ACPI and with the unified
> interface, but it doesn't have to be the obvious way.
> 
> We could do it like this:
> 
> // internal implementation, may be called from drivers with legacy bindings 
> struct gpio_desc *__fwnode_get_gpiod_from_property(struct fwnode_handle 
> *fwnode,
>const char *propname, int index)
> {
>   ... /* your current code */
> }
> 
> // recommended interface
> static inline struct gpio_desc *fwnode_get_gpiod(struct fwnode_handle *fwnode,
> int index)
> {
>   return __fwnode_get_gpiod_from_property(fwnode, "gpios", index);
> }
> 
> // alternative interface
> struct gpio_desc *fwnode_get_gpiod(struct fwnode_handle *fwnode, const char 
> *name)
> {
>   char propname[64];
>   int ret;
>   
>   ret = snprintf(propname, sizeof(propname), "%s-gpios", name);
>   if (ret > sizeof(propname))
>   return -EINVAL;
> 
>   return __fwnode_get_gpiod_from_property(fwnode, propname, 0);
> }
> 
> The above is just a suggestion, I'm hoping for the GPIO maintainers to
> provide more guidance if they have other ideas.

Actually, since the two last patches in the series, which currently are
the only users of these new functions, both pass "gpios" as the property
name and 0 as the index, I can simplify the functions so that (a)
fwnode_get_gpiod() takes fwnode and name and then simply passes 0 as the
index to either of_get_named_gpiod_flags() or acpi_get_gpiod_by_index()
and (b) devm_get_named_gpiod_from_child() takes only dev and fwnode (child)
and passes "gpios" as the property name to fwnode_get_gpiod().  The name
of devm_get_named_gpiod_from_child() could then be changed to something
like devm_get_gpiod_from_child() even.

If anyone in the future needs anything more general, they can simply
add more complexity to that code, but for now we can go for a simplified
interface just fine.

Rafael

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

[Update][PATCH v5 09/12] Driver core: Unified interface for firmware node properties

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Add new generic routines are provided for retrieving properties from
device description objects in the platform firmware in case there are
no struct device objects for them (either those objects have not been
created yet or they do not exist at all).

The following functions are provided:

fwnode_property_present()
fwnode_property_read_u8()
fwnode_property_read_u16()
fwnode_property_read_u32()
fwnode_property_read_u64()
fwnode_property_read_string()
fwnode_property_read_u8_array()
fwnode_property_read_u16_array()
fwnode_property_read_u32_array()
fwnode_property_read_u64_array()
fwnode_property_read_string_array()

in analogy with the corresponding functions for struct device added
previously.  For all of them, the first argument is a pointer to struct
fwnode_handle (new type) that allows a device description object
(depending on what platform firmware interface is in use) to be
obtained.

Add a new macro device_for_each_child_node() for iterating over the
children of the device description object associated with a given
device and a new function device_get_child_node_count() returning the
number of a given device's child nodes.

The interface covers both ACPI and Device Trees.

Suggested-by: Grant Likely 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Rafael J. Wysocki 
---

This applies on top of https://patchwork.kernel.org/patch/5101721/ .

It adds fwnode_property_read_bool() as a wrapper around 
fwnode_property_present()
and uses macros to generate the bodies of fwnode_property_read_*(), except for
fwnode_property_read_string_array() whose structure is a bit different from the
other functions.

Also added is the fresh ACK from Greg as the overall picture is still the same
as before.

Rafael

---
 drivers/acpi/scan.c  |   21 ++
 drivers/base/property.c  |  349 +++
 include/acpi/acpi_bus.h  |   17 ++
 include/linux/acpi.h |   26 +++
 include/linux/of.h   |   22 ++
 include/linux/property.h |   54 +++
 6 files changed, 489 insertions(+)

Index: linux-pm/include/linux/property.h
===
--- linux-pm.orig/include/linux/property.h
+++ linux-pm/include/linux/property.h
@@ -44,10 +44,64 @@ int device_property_read_u64_array(struc
 int device_property_read_string_array(struct device *dev, const char *propname,
  char **val, size_t nval);
 
+enum fwnode_type {
+   FWNODE_INVALID = 0,
+   FWNODE_OF,
+   FWNODE_ACPI,
+};
+
+struct fwnode_handle {
+   enum fwnode_type type;
+};
+
+bool fwnode_property_present(struct fwnode_handle *fwnode, const char 
*propname);
+int fwnode_property_read_u8(struct fwnode_handle *fwnode, const char *propname,
+   u8 *val);
+int fwnode_property_read_u16(struct fwnode_handle *fwnode, const char 
*propname,
+u16 *val);
+int fwnode_property_read_u32(struct fwnode_handle *fwnode, const char 
*propname,
+u32 *val);
+int fwnode_property_read_u64(struct fwnode_handle *fwnode, const char 
*propname,
+u64 *val);
+int fwnode_property_read_string(struct fwnode_handle *fwnode,
+   const char *propname, const char **val);
+int fwnode_property_read_u8_array(struct fwnode_handle *fwnode,
+ const char *propname, u8 *val,
+ size_t nval);
+int fwnode_property_read_u16_array(struct fwnode_handle *fwnode,
+  const char *propname, u16 *val,
+  size_t nval);
+int fwnode_property_read_u32_array(struct fwnode_handle *fwnode,
+  const char *propname, u32 *val,
+  size_t nval);
+int fwnode_property_read_u64_array(struct fwnode_handle *fwnode,
+  const char *propname, u64 *val,
+  size_t nval);
+int fwnode_property_read_string_array(struct fwnode_handle *fwnode,
+ const char *propname, char **val,
+ size_t nval);
+
+struct fwnode_handle *device_get_next_child_node(struct device *dev,
+struct fwnode_handle *child);
+
+#define device_for_each_child_node(dev, child) \
+   for (child = device_get_next_child_node(dev, NULL); child; \
+child = device_get_next_child_node(dev, child))
+
+void fwnode_handle_put(struct fwnode_handle *fwnode);
+
+unsigned int device_get_child_node_count(struct device *dev);
+
 static inline bool device_property_read_bool(struct device *dev,
 const char *propname)
 {
return device_property_present(dev, propname);
 }
 
+static inline bool fwnode_property_read_bool(struct fwnode_handle *fwnode,
+  

[Update][PATCH v5 02/12] Driver core: Unified device properties interface for platform firmware

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" 

Add a uniform interface by which device drivers can request device
properties from the platform firmware by providing a property name
and the corresponding data type.  The purpose of it is to help to
write portable code that won't depend on any particular platform
firmware interface.

The following general helper functions are added:

device_property_present()
device_property_read_u8()
device_property_read_u16()
device_property_read_u32()
device_property_read_u64()
device_property_read_string()
device_property_read_u8_array()
device_property_read_u16_array()
device_property_read_u32_array()
device_property_read_u64_array()
device_property_read_string_array()

The first one allows the caller to check if the given property is
present.  The next 5 of them allow single-valued properties of
various types to be retrieved in a uniform way.  The remaining 5 are
for reading properties with multiple values (arrays of either numbers
or strings).

The interface covers both ACPI and Device Trees.

This change set includes material from Mika Westerberg and Aaron Lu.

Signed-off-by: Aaron Lu 
Signed-off-by: Mika Westerberg 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Rafael J. Wysocki 
---

This adds device_property_read_bool() as a wrapper around 
device_property_present()
and uses macros to generate the bodies of device_property_read_*(), except for
device_property_read_string_array() that doesn't match the overall scheme 
exactly.

I believe that the Greg's ACK still applies. :-)

Rafael

---
 drivers/acpi/property.c  |  169 
 drivers/base/Makefile|2 
 drivers/base/property.c  |  276 +++
 drivers/of/base.c|  106 +++---
 include/linux/acpi.h |   32 +
 include/linux/of.h   |   22 +++
 include/linux/property.h |   53 +
 7 files changed, 643 insertions(+), 17 deletions(-)
 create mode 100644 drivers/base/property.c
 create mode 100644 include/linux/property.h

Index: linux-pm/include/linux/property.h
===
--- /dev/null
+++ linux-pm/include/linux/property.h
@@ -0,0 +1,53 @@
+/*
+ * property.h - Unified device property interface.
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Rafael J. Wysocki 
+ *  Mika Westerberg 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _LINUX_PROPERTY_H_
+#define _LINUX_PROPERTY_H_
+
+#include 
+
+struct device;
+
+enum dev_prop_type {
+   DEV_PROP_U8,
+   DEV_PROP_U16,
+   DEV_PROP_U32,
+   DEV_PROP_U64,
+   DEV_PROP_STRING,
+   DEV_PROP_MAX,
+};
+
+bool device_property_present(struct device *dev, const char *propname);
+int device_property_read_u8(struct device *dev, const char *propname, u8 *val);
+int device_property_read_u16(struct device *dev, const char *propname, u16 
*val);
+int device_property_read_u32(struct device *dev, const char *propname, u32 
*val);
+int device_property_read_u64(struct device *dev, const char *propname, u64 
*val);
+int device_property_read_string(struct device *dev, const char *propname,
+   const char **val);
+int device_property_read_u8_array(struct device *dev, const char *propname,
+ u8 *val, size_t nval);
+int device_property_read_u16_array(struct device *dev, const char *propname,
+  u16 *val, size_t nval);
+int device_property_read_u32_array(struct device *dev, const char *propname,
+  u32 *val, size_t nval);
+int device_property_read_u64_array(struct device *dev, const char *propname,
+  u64 *val, size_t nval);
+int device_property_read_string_array(struct device *dev, const char *propname,
+ char **val, size_t nval);
+
+static inline bool device_property_read_bool(struct device *dev,
+const char *propname)
+{
+   return device_property_present(dev, propname);
+}
+
+#endif /* _LINUX_PROPERTY_H_ */
Index: linux-pm/include/linux/of.h
===
--- linux-pm.orig/include/linux/of.h
+++ linux-pm/include/linux/of.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -263,6 +264,10 @@ extern int of_property_read_u32_array(co
  size_t sz);
 extern int of_property_read_u64(const struct device_node *np,
const char *propname, u64 *out_value);
+extern int of_property_read_u64_array(const struct device_node *np,
+ const char *propname,
+ u64 *out_values,
+ 

Re: [PATCH v5 09/12] Driver core: Unified interface for firmware node properties

[Rafael J. Wysocki]

On Saturday, October 18, 2014 04:55:20 PM Grant Likely wrote:
> On Fri, 17 Oct 2014 14:14:53 +0200
> , "Rafael J. Wysocki" 
>  wrote:
> > From: Rafael J. Wysocki 
> > 
> > Add new generic routines are provided for retrieving properties from
> > device description objects in the platform firmware in case there are
> > no struct device objects for them (either those objects have not been
> > created yet or they do not exist at all).
> > 
> > The following functions are provided:
> > 
> > fwnode_property_present()
> > fwnode_property_read_u8()
> > fwnode_property_read_u16()
> > fwnode_property_read_u32()
> > fwnode_property_read_u64()
> > fwnode_property_read_string()
> > fwnode_property_read_u8_array()
> > fwnode_property_read_u16_array()
> > fwnode_property_read_u32_array()
> > fwnode_property_read_u64_array()
> > fwnode_property_read_string_array()
> > 
> > in analogy with the corresponding functions for struct device added
> > previously.  For all of them, the first argument is a pointer to struct
> > fwnode_handle (new type) that allows a device description object
> > (depending on what platform firmware interface is in use) to be
> > obtained.
> > 
> > Add a new macro device_for_each_child_node() for iterating over the
> > children of the device description object associated with a given
> > device and a new function device_get_child_node_count() returning the
> > number of a given device's child nodes.
> > 
> > The interface covers both ACPI and Device Trees.
> 
> This is all *so much* better. I'm a lot happier.
> 
> I was about to make the comment that the implementation for
> device_property_read_*() should merely be wrappers around
> fwnode_property_read_*(), but when when I actually looked at it, I saw
> this:
> 
> In patch 2:
> int device_property_read_u8(struct device *dev, const char *propname, u8 *val)
> {
>   if (IS_ENABLED(CONFIG_OF) && dev->of_node)
>   return of_property_read_u8(dev->of_node, propname, val);
> 
>   return acpi_dev_prop_read(ACPI_COMPANION(dev), propname,
> DEV_PROP_U8, val);
> }
> 
> And in this patch:
> int fwnode_property_read_u8(struct fwnode_handle *fwnode, const char 
> *propname,
>   u8 *val)
> {
>   if (is_of_node(fwnode))
>   return of_property_read_u8(of_node(fwnode), propname, val);
>   else if (is_acpi_node(fwnode))
>   return acpi_dev_prop_read(acpi_node(fwnode), propname,
> DEV_PROP_U8, val);
> 
>   return -ENXIO;
> }
> 
> Making the device_property functions wrappers around fwnode_property_*
> wouldn't actually be great since it would need to decode the fwnode
> pointer twice.

Indeed.

> I do still think the functions above should be macro generated, just in
> terms of keeping the line count down, and I would suggest merging patches #2
> and #9.

Well, the changes in those patches are almost completely independent and patch
#9 is only actually needed for #11 and #12, so I'm not sure if that would be
better.  I certainly prefer splitting longer patches into pieces if that makes
sense and it does make sense to do so in this particular case IMHO.

> Something like:
> 
> #define define_fwnode_accessors(__type, __devprop_type) \
> int device_property_read_##__type(struct device *dev, \
>   const char *propname, __type *val) \
> { \
>   if (IS_ENABLED(CONFIG_OF) && dev->of_node) \
>   return of_property_read_##__type(dev->of_node, propname, val); \
>   return acpi_dev_prop_read(ACPI_COMPANION(dev), propname, \
> __devprop_type, val); \
> } \
> int fwnode_property_read_##__type(struct fwnode_handle *fwnode, \
>   const char *propname, __type *val) \
> { \
>   if (IS_ENABLED(CONFIG_OF) && is_of_node(fwnode)) \
>   return of_property_read_##__type(of_node(fwnode), propname, 
> val); \
>   else if (IS_ENABLED(CONFIG_ACPI) && is_acpi_node(fwnode)) \
>   return acpi_dev_prop_read(acpi_node(fwnode), propname, \
> __devprop_type, val); \
>   return -ENXIO; \
> }
> 
> define_fwnode_accessors(u8, DEV_PROP_U8);
> define_fwnode_accessors(u16, DEV_PROP_U16);
> define_fwnode_accessors(u32, DEV_PROP_U32);
> define_fwnode_accessors(u64, DEV_PROP_U64);
> 
> That significantly reduces the code size for these things.

So I was considering to do that, but eventually decided not to, because (1)
adding kerneldoc comments to such things looks odd and (2) (which IMO is
more important) this breaks LXR (for example, the thing at 
lxr.free-electrons.com
that some people, including me in particular, occasionally use to check how 
things
are defined).  And even if you used the old good grep to look for a definition 
of
fwnode_property_read_u8, say, this wouldn't work exactly as expected I'm 
afraid. ;-)

I would very much like to retain the headers at least for th

Re: [PATCH v5 09/12] Driver core: Unified interface for firmware node properties

[Rafael J. Wysocki]

On Monday, October 20, 2014 06:14:34 AM Greg Kroah-Hartman wrote:
> On Fri, Oct 17, 2014 at 02:14:53PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > Add new generic routines are provided for retrieving properties from
> > device description objects in the platform firmware in case there are
> > no struct device objects for them (either those objects have not been
> > created yet or they do not exist at all).
> > 
> > The following functions are provided:
> > 
> > fwnode_property_present()
> > fwnode_property_read_u8()
> > fwnode_property_read_u16()
> > fwnode_property_read_u32()
> > fwnode_property_read_u64()
> > fwnode_property_read_string()
> > fwnode_property_read_u8_array()
> > fwnode_property_read_u16_array()
> > fwnode_property_read_u32_array()
> > fwnode_property_read_u64_array()
> > fwnode_property_read_string_array()
> > 
> > in analogy with the corresponding functions for struct device added
> > previously.  For all of them, the first argument is a pointer to struct
> > fwnode_handle (new type) that allows a device description object
> > (depending on what platform firmware interface is in use) to be
> > obtained.
> > 
> > Add a new macro device_for_each_child_node() for iterating over the
> > children of the device description object associated with a given
> > device and a new function device_get_child_node_count() returning the
> > number of a given device's child nodes.
> > 
> > The interface covers both ACPI and Device Trees.
> > 
> > Suggested-by: Grant Likely 
> > Signed-off-by: Rafael J. Wysocki 
> 
> Acked-by: Greg Kroah-Hartman 

Thanks!

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

Re: [PATCH v5 09/12] Driver core: Unified interface for firmware node properties

[Rafael J. Wysocki]

On Saturday, October 18, 2014 11:35:21 AM Arnd Bergmann wrote:
> On Friday 17 October 2014 14:14:53 Rafael J. Wysocki wrote:
> > +/**
> > + * fwnode_property_present - check if a property of a firmware node is 
> > present
> > + * @fwnode: Firmware node whose property to check
> > + * @propname: Name of the property
> > + */
> > +bool fwnode_property_present(struct fwnode_handle *fwnode, const char 
> > *propname)
> > +{
> > +   if (is_of_node(fwnode))
> > +   return of_property_read_bool(of_node(fwnode), propname);
> > +   else if (is_acpi_node(fwnode))
> > +   return !acpi_dev_prop_get(acpi_node(fwnode), propname, 
> > NULL);
> > +
> > +   return false;
> > +}
> > +EXPORT_SYMBOL_GPL(fwnode_property_present);
> > 
> 
> Should this be
> 
>   return acpi_dev_prop_get(acpi_node(fwnode), propname, NULL);
> 
> without the '!'?

No, acpi_dev_prop_get() returns 0 on success. :-)

> I'm also unsure about the '_present' vs '_read_bool' naming. IIRC we had
> a long debate about this before we decided on 'read_bool' for DT, and
> I don't really want to start a new debate, but being consistent would
> be nice.
> 
> We could of course have
> 
> static inline bool fwnode_property_read_bool(struct fwnode_handle *fwnode, 
> const char *propname)
> {
>   return fwnode_property_present(fwnode, propname);
> }
> 
> which is completely redundant, but would help for drivers using the
> interface to document whether we are checking for bool property that
> we expect to be either empty or absent (_get_bool), vs checking for
> the presence of a non-empty property (_present).

I'm fine with that, so I'll add fwnode_property_read_bool() (and an analogous
wrapper for device_) to patches [02/12] and [09/12].

I'll be sending updates of them shortly, so please have a look at those.

Rafael

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

Re: [PATCH v5 00/12] Add ACPI _DSD and unified device properties support

[Rafael J. Wysocki]

On Saturday, October 18, 2014 10:49:59 AM Grant Likely wrote:
> On Sat, 18 Oct 2014 00:50 +0200
> , "Rafael J. Wysocki" 
>  wrote:
> > On Friday, October 17, 2014 08:04:52 PM Arnd Bergmann wrote:
> > > 
> > > On October 17, 2014 2:01:33 PM CEST, "Rafael J. Wysocki" 
> > >  wrote:
> > > >Hi Everyone,
> > > >
> > > >Hving had a couple of chats with Grant and Arnd during LinuxCon EU/LPC,
> > > >we
> > > >now have version 5 taking all feedback into account (hopefully).
> > > 
> > > Awesome, that was really fast. I'm currently on my way his me in
> > > the train, replying from my phone, but it looks good now. I'll have a more
> > > detailed look next week but I'm definitely happy to see this go in (to 
> > > next
> > > and 3.19) now, any details we still find can be fixed on top.
> > > 
> > > > In
> > > >short, if
> > > >we are passed a struct fwnode_handle pointer, we can get from it to the
> > > >appropriate device node pointer (either struct acpi_device or struct
> > > >device_node)
> > > >using container_of() after we've checked the type.  This is needed for
> > > >the code
> > > >that needs to access child nodes of a device in case when they don't
> > > >have
> > > >struct device representations (whatever the reason).  This has been
> > > >suggested
> > > >by Grant and pretty much everyone involved agrees that it's better that
> > > >the
> > > >alternatives presented so far.
> > > 
> > > Yes, it's nice enough that I now take back all the objections I had for 
> > > the
> > > child accessory API.
> > 
> > Cool, thanks!
> > 
> > I've just refreshed the device-properties branch of the linux-pm.git tree
> > and it contains the current material now (including a couple of build
> > fixes reported by the autobuild robot in patches [02/12] and [09/12]).
> > 
> > My plan is to merge this into the linux-next branch when 3.18-rc1 is out.
> 
> Wait for my ack please, but I should be able to review it this weekend
> or on Monday. I'm actually reviewing now, but I'm on a plane near the
> end of the flight. As soon as I get on the ground SIGFAMILY will
> interrupt me for a bit. :-)

Sure, I won't be trying to push things that you don't like :-)

Rafael

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

Re: [PATCH v5 00/12] Add ACPI _DSD and unified device properties support

[Greg Kroah-Hartman]

On Fri, Oct 17, 2014 at 11:49:45PM +0200, Rafael J. Wysocki wrote:
> On Friday, October 17, 2014 05:40:07 PM Greg Kroah-Hartman wrote:
> > On Fri, Oct 17, 2014 at 02:01:33PM +0200, Rafael J. Wysocki wrote:
> > > Hi Everyone,
> > > 
> > > Hving had a couple of chats with Grant and Arnd during LinuxCon EU/LPC, we
> > > now have version 5 taking all feedback into account (hopefully).
> > > 
> > > Changes have been made to patch [02/12] and to patches [09-12/12], 
> > > although
> > > in patches [10-12/12] they are fairly minor.  I have retained the Greg's
> > > ACK on patch [02/12], because it is essentially the same that have been
> > > posted aleady and ACKed by him (Greg, please let me know if I shouldn't
> > > do that) and all the ACKs on the remaining patches except for patch 
> > > [09/12]
> > > which is substantially different.  Still, if reviewers think that their
> > > ACKs don't apply any more, please let me know and I'll remove them.
> > 
> > No objection from me to keep my ACK on those patches, thanks for asking.
> 
> Well, that's just fair IMO. :-)
> 
> Does [09/12] look good too in particular?

Yes, I have no objections to it.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 09/12] Driver core: Unified interface for firmware node properties

[Greg Kroah-Hartman]

On Fri, Oct 17, 2014 at 02:14:53PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Add new generic routines are provided for retrieving properties from
> device description objects in the platform firmware in case there are
> no struct device objects for them (either those objects have not been
> created yet or they do not exist at all).
> 
> The following functions are provided:
> 
> fwnode_property_present()
> fwnode_property_read_u8()
> fwnode_property_read_u16()
> fwnode_property_read_u32()
> fwnode_property_read_u64()
> fwnode_property_read_string()
> fwnode_property_read_u8_array()
> fwnode_property_read_u16_array()
> fwnode_property_read_u32_array()
> fwnode_property_read_u64_array()
> fwnode_property_read_string_array()
> 
> in analogy with the corresponding functions for struct device added
> previously.  For all of them, the first argument is a pointer to struct
> fwnode_handle (new type) that allows a device description object
> (depending on what platform firmware interface is in use) to be
> obtained.
> 
> Add a new macro device_for_each_child_node() for iterating over the
> children of the device description object associated with a given
> device and a new function device_get_child_node_count() returning the
> number of a given device's child nodes.
> 
> The interface covers both ACPI and Device Trees.
> 
> Suggested-by: Grant Likely 
> Signed-off-by: Rafael J. Wysocki 

Acked-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 15/15] tpm/tpm_i2c_stm_st33: Increment driver version to 1.2.1.

[Christophe Ricard]

Many changes were added to the driver so increment the version.

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 162b91a..52869a2 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -1,6 +1,6 @@
 /*
  * STMicroelectronics TPM I2C Linux driver for TPM ST33ZP24
- * Copyright (C) 2009, 2010  STMicroelectronics
+ * Copyright (C) 2009, 2010, 2014  STMicroelectronics
  *
  * 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
@@ -15,7 +15,7 @@
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, see .
  *
- * STMicroelectronics version 1.2.0, Copyright (C) 2010
+ * STMicroelectronics version 1.2.1, Copyright (C) 2014
  * STMicroelectronics comes with ABSOLUTELY NO WARRANTY.
  * This is free software, and you are welcome to redistribute it
  * under certain conditions.
@@ -908,5 +908,5 @@ module_i2c_driver(tpm_stm_i2c_driver);
 
 MODULE_AUTHOR("Christophe Ricard (tpmsupp...@st.com)");
 MODULE_DESCRIPTION("STM TPM I2C ST33 Driver");
-MODULE_VERSION("1.2.0");
+MODULE_VERSION("1.2.1");
 MODULE_LICENSE("GPL");
-- 
1.9.1

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

[PATCH v4 14/15] tpm/tpm_i2c_stm_st33: Change License header to have up to date address information

[Christophe Ricard]

The Free Software Foundation may have mail address change.
In order to be sure to have up to date mail address give an url to
the license which includes accurate informations.

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c| 5 ++---
 include/linux/platform_data/tpm_i2c_stm_st33.h | 5 ++---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 231d38f..162b91a 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -12,9 +12,8 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
  *
  * STMicroelectronics version 1.2.0, Copyright (C) 2010
  * STMicroelectronics comes with ABSOLUTELY NO WARRANTY.
diff --git a/include/linux/platform_data/tpm_i2c_stm_st33.h 
b/include/linux/platform_data/tpm_i2c_stm_st33.h
index ec698f2..85775cf 100644
--- a/include/linux/platform_data/tpm_i2c_stm_st33.h
+++ b/include/linux/platform_data/tpm_i2c_stm_st33.h
@@ -12,9 +12,8 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
  *
  * STMicroelectronics version 1.2.0, Copyright (C) 2010
  * STMicroelectronics comes with ABSOLUTELY NO WARRANTY.
-- 
1.9.1

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

[PATCH v4 07/15] tpm/tpm_i2c_stm_st33: Replace tpm_st33_* function with tpm_stm_*

[Christophe Ricard]

For sanity, replace every tpm_st33_* with tpm_stm_*

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 50 ++---
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 4997eff..fdcdf9b 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -225,7 +225,7 @@ static int wait_for_serirq_timeout(struct tpm_chip *chip, 
bool condition,
status = 1;
}
return status;
-}
+} /* wait_for_serirq_timeout() */
 
 /*
  * tpm_stm_i2c_cancel, cancel is not implemented.
@@ -242,7 +242,7 @@ static void tpm_stm_i2c_cancel(struct tpm_chip *chip)
I2C_WRITE_DATA(tpm_dev, TPM_STS, &data, 1);
if (chip->vendor.irq)
wait_for_serirq_timeout(chip, 1, chip->vendor.timeout_a);
-}  /* tpm_stm_i2c_cancel() */
+} /* tpm_stm_i2c_cancel() */
 
 /*
  * tpm_stm_spi_status return the TPM_STS register
@@ -258,7 +258,7 @@ static u8 tpm_stm_i2c_status(struct tpm_chip *chip)
 
I2C_READ_DATA(tpm_dev, TPM_STS, &data, 1);
return data;
-}  /* tpm_stm_i2c_status() */
+} /* tpm_stm_i2c_status() */
 
 
 /*
@@ -592,7 +592,7 @@ out:
return size;
 }
 
-static bool tpm_st33_i2c_req_canceled(struct tpm_chip *chip, u8 status)
+static bool tpm_stm_i2c_req_canceled(struct tpm_chip *chip, u8 status)
 {
return (status == TPM_STS_COMMAND_READY);
 }
@@ -604,7 +604,7 @@ static const struct tpm_class_ops st_i2c_tpm = {
.status = tpm_stm_i2c_status,
.req_complete_mask = TPM_STS_DATA_AVAIL | TPM_STS_VALID,
.req_complete_val = TPM_STS_DATA_AVAIL | TPM_STS_VALID,
-   .req_canceled = tpm_st33_i2c_req_canceled,
+   .req_canceled = tpm_stm_i2c_req_canceled,
 };
 
 static int interrupts;
@@ -616,14 +616,14 @@ module_param(power_mgt, int, 0444);
 MODULE_PARM_DESC(power_mgt, "Power Management");
 
 /*
- * tpm_st33_i2c_probe initialize the TPM device
+ * tpm_stm_i2c_probe initialize the TPM device
  * @param: client, the i2c_client drescription (TPM I2C description).
  * @param: id, the i2c_device_id struct.
  * @return: 0 in case of success.
  *  -1 in other case.
  */
 static int
-tpm_st33_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id)
+tpm_stm_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id)
 {
int r;
u8 intmask;
@@ -748,12 +748,12 @@ end:
 }
 
 /*
- * tpm_st33_i2c_remove remove the TPM device
+ * tpm_stm_i2c_remove remove the TPM device
  * @param: client, the i2c_client drescription (TPM I2C description).
clear_bit(0, &chip->is_open);
  * @return: 0 in case of success.
  */
-static int tpm_st33_i2c_remove(struct i2c_client *client)
+static int tpm_stm_i2c_remove(struct i2c_client *client)
 {
struct tpm_chip *chip =
(struct tpm_chip *) i2c_get_clientdata(client);
@@ -766,12 +766,12 @@ static int tpm_st33_i2c_remove(struct i2c_client *client)
 
 #ifdef CONFIG_PM_SLEEP
 /*
- * tpm_st33_i2c_pm_suspend suspend the TPM device
+ * tpm_stm_i2c_pm_suspend suspend the TPM device
  * @param: client, the i2c_client drescription (TPM I2C description).
  * @param: mesg, the power management message.
  * @return: 0 in case of success.
  */
-static int tpm_st33_i2c_pm_suspend(struct device *dev)
+static int tpm_stm_i2c_pm_suspend(struct device *dev)
 {
struct st33zp24_platform_data *pin_infos = dev->platform_data;
int r = 0;
@@ -781,14 +781,14 @@ static int tpm_st33_i2c_pm_suspend(struct device *dev)
else
r = tpm_pm_suspend(dev);
return r;
-}  /* tpm_st33_i2c_suspend() */
+} /* tpm_stm_i2c_suspend() */
 
 /*
- * tpm_st33_i2c_pm_resume resume the TPM device
+ * tpm_stm_i2c_pm_resume resume the TPM device
  * @param: client, the i2c_client drescription (TPM I2C description).
  * @return: 0 in case of success.
  */
-static int tpm_st33_i2c_pm_resume(struct device *dev)
+static int tpm_stm_i2c_pm_resume(struct device *dev)
 {
struct tpm_chip *chip = dev_get_drvdata(dev);
struct st33zp24_platform_data *pin_infos = dev->platform_data;
@@ -807,28 +807,28 @@ static int tpm_st33_i2c_pm_resume(struct device *dev)
tpm_do_selftest(chip);
}
return r;
-}  /* tpm_st33_i2c_pm_resume() */
+} /* tpm_stm_i2c_pm_resume() */
 #endif
 
-static const struct i2c_device_id tpm_st33_i2c_id[] = {
+static const struct i2c_device_id tpm_stm_i2c_id[] = {
{TPM_ST33_I2C, 0},
{}
 };
-MODULE_DEVICE_TABLE(i2c, tpm_st33_i2c_id);
-static SIMPLE_DEV_PM_OPS(tpm_st33_i2c_ops, tpm_st33_i2c_pm_suspend,
-   tpm_st33_i2c_pm_resume);
-static struct i2c_driver tpm_st33_i2c_driver = {
+MODULE_DEVICE_TABLE(i2c, tpm_stm_i2c_id);
+static SIMPLE_DEV_PM_OPS(tpm_stm_i2c_ops, tpm_stm_i2c_p

[PATCH v4 12/15] tpm/tpm_i2c_stm_st33: Remove useless i2c read on interrupt registers

[Christophe Ricard]

Remove useless i2c read on TPM_INT_ENABLE and TPM_INT_STATUS

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 5431a92..4bbe3cd 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -783,10 +783,6 @@ tpm_stm_i2c_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
goto _tpm_clean_answer;
}
 
-   r = I2C_READ_DATA(tpm_dev, TPM_INT_ENABLE, &intmask, 1);
-   if (r < 0)
-   goto _tpm_clean_answer;
-
intmask |= TPM_INTF_CMD_READY_INT
|  TPM_INTF_STS_VALID_INT
|  TPM_INTF_DATA_AVAIL_INT;
@@ -800,10 +796,6 @@ tpm_stm_i2c_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
if (r < 0)
goto _tpm_clean_answer;
 
-   r = I2C_READ_DATA(tpm_dev, TPM_INT_STATUS, &intmask, 1);
-   if (r < 0)
-   goto _tpm_clean_answer;
-
chip->vendor.irq = client->irq;
 
disable_irq_nosync(chip->vendor.irq);
-- 
1.9.1

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

[PATCH v4 00/15] ST33 I2C TPM driver cleanup

[Christophe Ricard]

Hi Peter,

This new patchset version is taking into account as much as possible
Jason Gunthorpe feedbacks. I hope, i am not missing any.

It still brings:
- Some few code clean up from code style up to structure
- Device tree support keeping static platform data configuration support.
- Fixes & improvement for irq support.
- Update the GPLv2 license header

I am also adding the mention Reviewed-By: Jason Gunthorpe 

on all those patches. 
Jason, please feel free to let me know if i am mistaking here. :).

This patchset apply on top of James Morris linux-security tree
on top of 594081ee7145cc30a3977cb4e218f81213b63dc5 on next branch
Hope i am targetting to correct tree.

The full patchset got also crosschecked by Jean-Luc here in copy.

Best Regards
Christophe

Christophe Ricard (15):
  tpm/tpm_i2c_stm_st33: Update Kconfig in order to be inline to other
similar product
  tpm/tpm_i2c_stm_st33: Fix few coding style error reported by
scripts/checkpatch.pl
  tpm/tpm_i2c_stm_st33: Move tpm registers to tpm_i2c_stm_st33.c
  tpm/tpm_i2c_stm_st33: Add new tpm_stm_dev structure and remove
tpm_i2c_buffer[0], [1] buffer.
  tpm/tpm_i2c_stm_st33: Remove reference to io_serirq
  tpm/tpm_i2c_stm_st33: Replace err/rc/ret by r for a function return
code
  tpm/tpm_i2c_stm_st33: Replace tpm_st33_* function with tpm_stm_*
  tpm/tpm_i2c_stm_st33: Add devicetree structure
  tpm/tpm_i2c_stm_st33/dts/st33zp24_i2c: Add DTS Documentation
  tpm/tpm_i2c_stm_st33: Few code cleanup
  tpm/tpm_i2c_stm_st33: Interrupt management improvement
  tpm/tpm_i2c_stm_st33: Remove useless i2c read on interrupt registers
  tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send
  tpm/tpm_i2c_stm_st33: Change License header to have up to date address
information
  tpm/tpm_i2c_stm_st33: Increment driver version to 1.2.1.

 .../devicetree/bindings/security/tpm/st33zp24.txt  |  36 ++
 drivers/char/tpm/Kconfig   |   4 +-
 drivers/char/tpm/Makefile  |   2 +-
 drivers/char/tpm/tpm_i2c_stm_st33.c| 675 +++--
 drivers/char/tpm/tpm_i2c_stm_st33.h|  61 --
 include/linux/platform_data/tpm_i2c_stm_st33.h |  39 ++
 6 files changed, 449 insertions(+), 368 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/st33zp24.txt
 delete mode 100644 drivers/char/tpm/tpm_i2c_stm_st33.h
 create mode 100644 include/linux/platform_data/tpm_i2c_stm_st33.h

-- 
1.9.1

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

[PATCH v4 05/15] tpm/tpm_i2c_stm_st33: Remove reference to io_serirq

[Christophe Ricard]

The serirq gpio pin is used only as interrupt. After driver initialization,
the serirq signal is always used through interrupt and never with gpio
kernel API.

The irq can then be initialized during the platform_data definition within the 
client->irq pin.

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c| 13 +++--
 include/linux/platform_data/tpm_i2c_stm_st33.h |  1 -
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 07ce463..71ef1da 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -104,7 +104,6 @@ struct tpm_stm_dev {
struct completion irq_detection;
struct tpm_chip *chip;
u8 buf[TPM_BUFSIZE + 1];
-   int io_serirq;
int io_lpcpd;
 };
 
@@ -690,18 +689,15 @@ tpm_st33_i2c_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
err = -ENODEV;
goto _tpm_clean_answer;
}
-   err = gpio_request(platform_data->io_serirq, "TPM IO_SERIRQ");
-   if (err)
-   goto _gpio_init2;
 
clear_interruption(tpm_dev);
-   err = request_irq(gpio_to_irq(platform_data->io_serirq),
+   err = request_irq(client->irq,
&tpm_ioserirq_handler,
IRQF_TRIGGER_HIGH,
"TPM SERIRQ management", chip);
if (err < 0) {
dev_err(chip->dev , "TPM SERIRQ signals %d not 
available\n",
-   gpio_to_irq(platform_data->io_serirq));
+   client->irq);
goto _irq_set;
}
 
@@ -740,10 +736,7 @@ tpm_st33_i2c_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
dev_info(chip->dev, "TPM I2C Initialized\n");
return 0;
 _irq_set:
-   free_irq(gpio_to_irq(platform_data->io_serirq), (void *)chip);
-_gpio_init2:
-   if (interrupts)
-   gpio_free(platform_data->io_serirq);
+   free_irq(client->irq, (void *)chip);
 _gpio_init1:
if (power_mgt)
gpio_free(platform_data->io_lpcpd);
diff --git a/include/linux/platform_data/tpm_i2c_stm_st33.h 
b/include/linux/platform_data/tpm_i2c_stm_st33.h
index c5e4b7f..ec698f2 100644
--- a/include/linux/platform_data/tpm_i2c_stm_st33.h
+++ b/include/linux/platform_data/tpm_i2c_stm_st33.h
@@ -34,7 +34,6 @@
 #define TPM_ST33_I2C   "st33zp24_i2c"
 
 struct st33zp24_platform_data {
-   int io_serirq;
int io_lpcpd;
 };
 
-- 
1.9.1

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

[PATCH v4 04/15] tpm/tpm_i2c_stm_st33: Add new tpm_stm_dev structure and remove tpm_i2c_buffer[0], [1] buffer.

[Christophe Ricard]

In order to clean big buffers in st33zp24_platform_data structure,
replace with tpm_stm_dev for driver internal usage.
As only one buffer is really necessary replace with buf field.

In the mean time move tpm_i2c_stm_st33.h to include/linux/platform_data.

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c| 198 +++--
 drivers/char/tpm/tpm_i2c_stm_st33.h|  44 --
 include/linux/platform_data/tpm_i2c_stm_st33.h |  41 +
 3 files changed, 130 insertions(+), 153 deletions(-)
 delete mode 100644 drivers/char/tpm/tpm_i2c_stm_st33.h
 create mode 100644 include/linux/platform_data/tpm_i2c_stm_st33.h

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 8a8fc10..07ce463 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -41,7 +41,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -49,6 +48,7 @@
 #include 
 #include 
 
+#include 
 #include "tpm.h"
 
 #define TPM_ACCESS 0x0
@@ -67,7 +67,7 @@
 #define TPM_BUFSIZE2048
 
 #define LOCALITY0  0
-#include "tpm_i2c_stm_st33.h"
+
 
 enum stm33zp24_access {
TPM_ACCESS_VALID = 0x80,
@@ -99,6 +99,15 @@ enum tis_defaults {
TIS_LONG_TIMEOUT = 2000,
 };
 
+struct tpm_stm_dev {
+   struct i2c_client *client;
+   struct completion irq_detection;
+   struct tpm_chip *chip;
+   u8 buf[TPM_BUFSIZE + 1];
+   int io_serirq;
+   int io_lpcpd;
+};
+
 /*
  * write8_reg
  * Send byte to the TIS register according to the ST33ZP24 I2C protocol.
@@ -107,17 +116,12 @@ enum tis_defaults {
  * @param: tpm_size, The length of the data
  * @return: Returns negative errno, or else the number of bytes written.
  */
-static int write8_reg(struct i2c_client *client, u8 tpm_register,
+static int write8_reg(struct tpm_stm_dev *tpm_dev, u8 tpm_register,
  u8 *tpm_data, u16 tpm_size)
 {
-   struct st33zp24_platform_data *pin_infos;
-
-   pin_infos = client->dev.platform_data;
-
-   pin_infos->tpm_i2c_buffer[0][0] = tpm_register;
-   memcpy(&pin_infos->tpm_i2c_buffer[0][1], tpm_data, tpm_size);
-   return i2c_master_send(client, pin_infos->tpm_i2c_buffer[0],
-   tpm_size + 1);
+   tpm_dev->buf[0] = tpm_register;
+   memcpy(tpm_dev->buf + 1, tpm_data, tpm_size);
+   return i2c_master_send(tpm_dev->client, tpm_dev->buf, tpm_size + 1);
 } /* write8_reg() */
 
 /*
@@ -128,50 +132,50 @@ static int write8_reg(struct i2c_client *client, u8 
tpm_register,
  * @param: tpm_size, tpm TPM response size to read.
  * @return: number of byte read successfully: should be one if success.
  */
-static int read8_reg(struct i2c_client *client, u8 tpm_register,
+static int read8_reg(struct tpm_stm_dev *tpm_dev, u8 tpm_register,
u8 *tpm_data, int tpm_size)
 {
u8 status = 0;
u8 data;
 
data = TPM_DUMMY_BYTE;
-   status = write8_reg(client, tpm_register, &data, 1);
+   status = write8_reg(tpm_dev, tpm_register, &data, 1);
if (status == 2)
-   status = i2c_master_recv(client, tpm_data, tpm_size);
+   status = i2c_master_recv(tpm_dev->client, tpm_data, tpm_size);
return status;
 } /* read8_reg() */
 
 /*
  * I2C_WRITE_DATA
  * Send byte to the TIS register according to the ST33ZP24 I2C protocol.
- * @param: client, the chip description
+ * @param: tpm_dev, the chip description
  * @param: tpm_register, the tpm tis register where the data should be written
  * @param: tpm_data, the tpm_data to write inside the tpm_register
  * @param: tpm_size, The length of the data
  * @return: number of byte written successfully: should be one if success.
  */
-#define I2C_WRITE_DATA(client, tpm_register, tpm_data, tpm_size) \
-   (write8_reg(client, tpm_register | \
+#define I2C_WRITE_DATA(tpm_dev, tpm_register, tpm_data, tpm_size) \
+   (write8_reg(tpm_dev, tpm_register | \
TPM_WRITE_DIRECTION, tpm_data, tpm_size))
 
 /*
  * I2C_READ_DATA
  * Recv byte from the TIS register according to the ST33ZP24 I2C protocol.
- * @param: tpm, the chip description
+ * @param: tpm_dev, the chip description
  * @param: tpm_register, the tpm tis register where the data should be read
  * @param: tpm_data, the TPM response
  * @param: tpm_size, tpm TPM response size to read.
  * @return: number of byte read successfully: should be one if success.
  */
-#define I2C_READ_DATA(client, tpm_register, tpm_data, tpm_size) \
-   (read8_reg(client, tpm_register, tpm_data, tpm_size))
+#define I2C_READ_DATA(tpm_dev, tpm_register, tpm_data, tpm_size) \
+   (read8_reg(tpm_dev, tpm_register, tpm_data, tpm_size))
 
 /*
  * clear_interruption
  * clear the TPM interrupt register.
  * @param: tpm, the chip description
  */
-static void clear_interruption(struct i2c_client *client)

[PATCH v4 06/15] tpm/tpm_i2c_stm_st33: Replace err/rc/ret by r for a function return code

[Christophe Ricard]

Some functions return err, rc or ret for a status code.

Return r instead for all of them.

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 97 ++---
 1 file changed, 48 insertions(+), 49 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 71ef1da..4997eff 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -292,7 +292,7 @@ static int check_locality(struct tpm_chip *chip)
 static int request_locality(struct tpm_chip *chip)
 {
unsigned long stop;
-   long rc;
+   long r;
struct tpm_stm_dev *tpm_dev;
u8 data;
 
@@ -302,15 +302,15 @@ static int request_locality(struct tpm_chip *chip)
return chip->vendor.locality;
 
data = TPM_ACCESS_REQUEST_USE;
-   rc = I2C_WRITE_DATA(tpm_dev, TPM_ACCESS, &data, 1);
-   if (rc < 0)
+   r = I2C_WRITE_DATA(tpm_dev, TPM_ACCESS, &data, 1);
+   if (r < 0)
goto end;
 
if (chip->vendor.irq) {
-   rc = wait_for_serirq_timeout(chip, (check_locality
+   r = wait_for_serirq_timeout(chip, (check_locality
   (chip) >= 0),
  chip->vendor.timeout_a);
-   if (rc > 0)
+   if (r > 0)
return chip->vendor.locality;
} else {
stop = jiffies + chip->vendor.timeout_a;
@@ -320,9 +320,9 @@ static int request_locality(struct tpm_chip *chip)
msleep(TPM_TIMEOUT);
} while (time_before(jiffies, stop));
}
-   rc = -EACCES;
+   r = -EACCES;
 end:
-   return rc;
+   return r;
 } /* request_locality() */
 
 /*
@@ -389,14 +389,14 @@ static int wait_for_stat(struct tpm_chip *chip, u8 mask, 
unsigned long timeout,
 wait_queue_head_t *queue)
 {
unsigned long stop;
-   long rc;
+   long r;
u8 status;
 
 if (chip->vendor.irq) {
-   rc = wait_for_serirq_timeout(chip, ((tpm_stm_i2c_status
+   r = wait_for_serirq_timeout(chip, ((tpm_stm_i2c_status
(chip) & mask) ==
   mask), timeout);
-   if (rc > 0)
+   if (r > 0)
return 0;
} else {
stop = jiffies + timeout;
@@ -476,7 +476,7 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned 
char *buf,
 {
u32 status, i, size;
int burstcnt = 0;
-   int ret;
+   int r;
u8 data;
struct i2c_client *client;
struct tpm_stm_dev *tpm_dev;
@@ -491,9 +491,9 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned 
char *buf,
 
client->flags = 0;
 
-   ret = request_locality(chip);
-   if (ret < 0)
-   return ret;
+   r = request_locality(chip);
+   if (r < 0)
+   return r;
 
status = tpm_stm_i2c_status(chip);
if ((status & TPM_STS_COMMAND_READY) == 0) {
@@ -501,7 +501,7 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned 
char *buf,
if (wait_for_stat
(chip, TPM_STS_COMMAND_READY, chip->vendor.timeout_b,
 &chip->vendor.int_queue) < 0) {
-   ret = -ETIME;
+   r = -ETIME;
goto out_err;
}
}
@@ -511,8 +511,8 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned 
char *buf,
if (burstcnt < 0)
return burstcnt;
size = min_t(int, len - i - 1, burstcnt);
-   ret = I2C_WRITE_DATA(tpm_dev, TPM_DATA_FIFO, buf, size);
-   if (ret < 0)
+   r = I2C_WRITE_DATA(tpm_dev, TPM_DATA_FIFO, buf, size);
+   if (r < 0)
goto out_err;
 
i += size;
@@ -520,17 +520,17 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, 
unsigned char *buf,
 
status = tpm_stm_i2c_status(chip);
if ((status & TPM_STS_DATA_EXPECT) == 0) {
-   ret = -EIO;
+   r = -EIO;
goto out_err;
}
 
-   ret = I2C_WRITE_DATA(tpm_dev, TPM_DATA_FIFO, buf + len - 1, 1);
-   if (ret < 0)
+   r = I2C_WRITE_DATA(tpm_dev, TPM_DATA_FIFO, buf + len - 1, 1);
+   if (r < 0)
goto out_err;
 
status = tpm_stm_i2c_status(chip);
if ((status & TPM_STS_DATA_EXPECT) != 0) {
-   ret = -EIO;
+   r = -EIO;
goto out_err;
}
 
@@ -541,7 +541,7 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned 
char *buf,
 out_err:
tpm_stm_i2c_cancel(chip);
release_locality(chip);
-   re

[PATCH v4 08/15] tpm/tpm_i2c_stm_st33: Add devicetree structure

[Christophe Ricard]

Add tpm_stm_st33_i2c dts structure keeping backward compatibility
with static platform_data support as well.
In the mean time to easy this update and to make it much simpler, we:
- Moved all gpio_request to devm_gpio_request_one primitive
- Moved request_irq to devm_request_irq

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 166 +---
 1 file changed, 115 insertions(+), 51 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index fdcdf9b..7339e84 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -47,6 +47,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include "tpm.h"
@@ -607,13 +609,80 @@ static const struct tpm_class_ops st_i2c_tpm = {
.req_canceled = tpm_stm_i2c_req_canceled,
 };
 
-static int interrupts;
-module_param(interrupts, int, 0444);
-MODULE_PARM_DESC(interrupts, "Enable interrupts");
+#ifdef CONFIG_OF
+static int tpm_stm_i2c_of_request_resources(struct tpm_chip *chip)
+{
+   struct device_node *pp;
+   struct tpm_stm_dev *tpm_dev = (struct tpm_stm_dev *)TPM_VPRIV(chip);
+   struct i2c_client *client = tpm_dev->client;
+
+   int gpio;
+   int r;
+
+   pp = client->dev.of_node;
+   if (!pp) {
+   dev_err(chip->dev, "No platform data\n");
+   return -ENODEV;
+   }
 
-static int power_mgt = 1;
-module_param(power_mgt, int, 0444);
-MODULE_PARM_DESC(power_mgt, "Power Management");
+   /* Get GPIO from device tree */
+   gpio = of_get_named_gpio(pp, "lpcpd-gpios", 0);
+   if (gpio < 0) {
+   dev_err(chip->dev, "Failed to retrieve lpcpd-gpios from 
dts.\n");
+   tpm_dev->io_lpcpd = -1;
+   /*
+* lpcpd pin is not specified. This is not an issue as
+* power management can be also managed by TPM specific
+* commands. So leave with a success status code.
+*/
+   return 0;
+   }
+   /* GPIO request and configuration */
+   r = devm_gpio_request_one(&client->dev, gpio,
+   GPIOF_OUT_INIT_HIGH, "TPM IO LPCPD");
+   if (r) {
+   dev_err(chip->dev, "Failed to request lpcpd pin\n");
+   return -ENODEV;
+   }
+   tpm_dev->io_lpcpd = gpio;
+
+   return 0;
+}
+#else
+static int tpm_stm_i2c_of_request_resources(struct i2c_client *client)
+{
+   return -ENODEV;
+}
+#endif
+
+static int tpm_stm_i2c_request_resources(struct i2c_client *client,
+struct tpm_chip *chip)
+{
+   struct st33zp24_platform_data *pdata;
+   struct tpm_stm_dev *tpm_dev = (struct tpm_stm_dev *)TPM_VPRIV(chip);
+   int r;
+
+   pdata = client->dev.platform_data;
+   if (pdata == NULL) {
+   pr_err("No platform data\n");
+   return -EINVAL;
+   }
+
+   /* store for late use */
+   tpm_dev->io_lpcpd = pdata->io_lpcpd;
+
+   if (gpio_is_valid(pdata->io_lpcpd)) {
+   r = devm_gpio_request_one(&client->dev,
+   pdata->io_lpcpd, GPIOF_OUT_INIT_HIGH,
+   "TPM IO_LPCPD");
+   if (r) {
+   dev_err(chip->dev, "%s : reset gpio_request failed\n", 
__FILE__);
+   return r;
+   }
+   }
+
+   return 0;
+}
 
 /*
  * tpm_stm_i2c_probe initialize the TPM device
@@ -634,31 +703,18 @@ tpm_stm_i2c_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
if (client == NULL) {
pr_info("%s: i2c client is NULL. Device not accessible.\n",
__func__);
-   r = -ENODEV;
-   goto end;
+   return -ENODEV;
}
 
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
dev_info(&client->dev, "client not i2c capable\n");
-   r = -ENODEV;
-   goto end;
+   return -ENODEV;
}
 
tpm_dev = devm_kzalloc(&client->dev, sizeof(struct tpm_stm_dev),
   GFP_KERNEL);
-   if (!tpm_dev) {
-   dev_info(&client->dev, "cannot allocate memory for tpm data\n");
-   r = -ENOMEM;
-   goto _tpm_clean_answer;
-   }
-
-   platform_data = client->dev.platform_data;
-
-   if (!platform_data) {
-   dev_info(&client->dev, "chip not available\n");
-   r = -ENODEV;
-   goto _tpm_clean_answer;
-   }
+   if (!tpm_dev)
+   return -ENOMEM;
 
chip = tpm_register_hardware(&client->dev, &st_i2c_tpm);
if (!chip) {
@@ -669,6 +725,17 @@ tpm_stm_i2c_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
TPM_VPRIV(chip) = tpm_dev;
tpm_dev->client = client;
 
+   p

[PATCH v4 03/15] tpm/tpm_i2c_stm_st33: Move tpm registers to tpm_i2c_stm_st33.c

[Christophe Ricard]

Move tpm registers to tpm_i2c_stm_st33.c.

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 17 +
 drivers/char/tpm/tpm_i2c_stm_st33.h | 17 -
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 52d80ef..8a8fc10 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -50,6 +50,23 @@
 #include 
 
 #include "tpm.h"
+
+#define TPM_ACCESS 0x0
+#define TPM_STS0x18
+#define TPM_HASH_END   0x20
+#define TPM_DATA_FIFO  0x24
+#define TPM_HASH_DATA  0x24
+#define TPM_HASH_START 0x28
+#define TPM_INTF_CAPABILITY0x14
+#define TPM_INT_STATUS 0x10
+#define TPM_INT_ENABLE 0x08
+
+#define TPM_DUMMY_BYTE 0xAA
+#define TPM_WRITE_DIRECTION0x80
+#define TPM_HEADER_SIZE10
+#define TPM_BUFSIZE2048
+
+#define LOCALITY0  0
 #include "tpm_i2c_stm_st33.h"
 
 enum stm33zp24_access {
diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.h 
b/drivers/char/tpm/tpm_i2c_stm_st33.h
index 439a432..3041271 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.h
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.h
@@ -30,23 +30,6 @@
 #ifndef __STM_ST33_TPM_I2C_MAIN_H__
 #define __STM_ST33_TPM_I2C_MAIN_H__
 
-#define TPM_ACCESS (0x0)
-#define TPM_STS(0x18)
-#define TPM_HASH_END   (0x20)
-#define TPM_DATA_FIFO  (0x24)
-#define TPM_HASH_DATA  (0x24)
-#define TPM_HASH_START (0x28)
-#define TPM_INTF_CAPABILITY(0x14)
-#define TPM_INT_STATUS (0x10)
-#define TPM_INT_ENABLE (0x08)
-
-#define TPM_DUMMY_BYTE 0xAA
-#define TPM_WRITE_DIRECTION0x80
-#define TPM_HEADER_SIZE10
-#define TPM_BUFSIZE2048
-
-#define LOCALITY0  0
-
 #define TPM_ST33_I2C   "st33zp24_i2c"
 
 struct st33zp24_platform_data {
-- 
1.9.1

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

[PATCH v4 01/15] tpm/tpm_i2c_stm_st33: Update Kconfig in order to be inline to other similar product

[Christophe Ricard]

STMicroelectronics i2c tpm is the only one to have a different tristate
label.

Rename it "TPM Interface Specification 1.2 Interface (I2C - STMicroelectronics)"

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/Kconfig  | 4 ++--
 drivers/char/tpm/Makefile | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index c54cac3..edfb45c 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -100,8 +100,8 @@ config TCG_IBMVTPM
  will be accessible from within Linux.  To compile this driver
  as a module, choose M here; the module will be called tpm_ibmvtpm.
 
-config TCG_ST33_I2C
-   tristate "STMicroelectronics ST33 I2C TPM"
+config TCG_TIS_I2C_ST33
+   tristate "TPM Interface Specification 1.2 Interface (I2C - 
STMicroelectronics)"
depends on I2C
depends on GPIOLIB
---help---
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index 4d85dd6..7f54dae 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -20,5 +20,5 @@ obj-$(CONFIG_TCG_NSC) += tpm_nsc.o
 obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o
 obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o
 obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
-obj-$(CONFIG_TCG_ST33_I2C) += tpm_i2c_stm_st33.o
+obj-$(CONFIG_TCG_TIS_I2C_ST33) += tpm_i2c_stm_st33.o
 obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
-- 
1.9.1

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

[PATCH v4 02/15] tpm/tpm_i2c_stm_st33: Fix few coding style error reported by scripts/checkpatch.pl

[Christophe Ricard]

Fix:
- WARNING: Missing a blank line after declarations
- WARNING: braces {} are not necessary for any arm of this statement

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 4669e37..52d80ef 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -157,6 +157,7 @@ static int read8_reg(struct i2c_client *client, u8 
tpm_register,
 static void clear_interruption(struct i2c_client *client)
 {
u8 interrupt;
+
I2C_READ_DATA(client, TPM_INT_STATUS, &interrupt, 1);
I2C_WRITE_DATA(client, TPM_INT_STATUS, &interrupt, 1);
I2C_READ_DATA(client, TPM_INT_STATUS, &interrupt, 1);
@@ -233,6 +234,7 @@ static u8 tpm_stm_i2c_status(struct tpm_chip *chip)
 {
struct i2c_client *client;
u8 data;
+
client = (struct i2c_client *)TPM_VPRIV(chip);
 
I2C_READ_DATA(client, TPM_STS, &data, 1);
@@ -784,11 +786,11 @@ static int tpm_st33_i2c_pm_suspend(struct device *dev)
struct st33zp24_platform_data *pin_infos = dev->platform_data;
int ret = 0;
 
-   if (power_mgt) {
+   if (power_mgt)
gpio_set_value(pin_infos->io_lpcpd, 0);
-   } else {
+   else
ret = tpm_pm_suspend(dev);
-   }
+
return ret;
 }  /* tpm_st33_i2c_suspend() */
 
-- 
1.9.1

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

[PATCH v4 13/15] tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send

[Christophe Ricard]

When sending data in tpm_stm_i2c_send, each loop iteration send buf.
Send buf + i instead as the goal of this for loop is to send a number
of byte from buf that fit in burstcnt. Once those byte are sent, we are
supposed to send the next ones.

The driver was working because the burstcount value returns always the maximum 
size for a TPM
command or response. (0x800 for a command and 0x400 for a response).

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 4bbe3cd..231d38f 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -532,7 +532,7 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned 
char *buf,
if (burstcnt < 0)
return burstcnt;
size = min_t(int, len - i - 1, burstcnt);
-   r = I2C_WRITE_DATA(tpm_dev, TPM_DATA_FIFO, buf, size);
+   r = I2C_WRITE_DATA(tpm_dev, TPM_DATA_FIFO, buf + i, size);
if (r < 0)
goto out_err;
 
-- 
1.9.1

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

[PATCH v4 11/15] tpm/tpm_i2c_stm_st33: Interrupt management improvement

[Christophe Ricard]

Improve the irq management by using a new function wait_for_stat.
Instead of using a completion struct, we rely on the waitqueue read_queue
and int_queue from chip->vendor field.

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 201 
 1 file changed, 111 insertions(+), 90 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 54d1728..5431a92 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -103,9 +104,9 @@ enum tis_defaults {
 
 struct tpm_stm_dev {
struct i2c_client *client;
-   struct completion irq_detection;
struct tpm_chip *chip;
u8 buf[TPM_BUFSIZE + 1];
+   u32 intrs;
int io_lpcpd;
 };
 
@@ -175,61 +176,18 @@ static int read8_reg(struct tpm_stm_dev *tpm_dev, u8 
tpm_register,
  * clear_interruption
  * clear the TPM interrupt register.
  * @param: tpm, the chip description
+ * @return: the TPM_INT_STATUS value
  */
-static void clear_interruption(struct tpm_stm_dev *tpm_dev)
+static u8 clear_interruption(struct tpm_stm_dev *tpm_dev)
 {
u8 interrupt;
 
-   I2C_READ_DATA(client, TPM_INT_STATUS, &interrupt, 1);
-   I2C_WRITE_DATA(client, TPM_INT_STATUS, &interrupt, 1);
-   I2C_READ_DATA(client, TPM_INT_STATUS, &interrupt, 1);
+   I2C_READ_DATA(tpm_dev, TPM_INT_STATUS, &interrupt, 1);
+   I2C_WRITE_DATA(tpm_dev, TPM_INT_STATUS, &interrupt, 1);
+   return interrupt;
 } /* clear_interruption() */
 
 /*
- * _wait_for_interrupt_serirq_timeout
- * @param: tpm, the chip description
- * @param: timeout, the timeout of the interrupt
- * @return: the status of the interruption.
- */
-static long _wait_for_interrupt_serirq_timeout(struct tpm_chip *chip,
-   unsigned long timeout)
-{
-   long status;
-   struct i2c_client *client;
-   struct tpm_stm_dev *tpm_dev;
-
-   tpm_dev = (struct tpm_stm_dev *)TPM_VPRIV(chip);
-   client = tpm_dev->client;
-
-   status = wait_for_completion_interruptible_timeout(
-   &tpm_dev->irq_detection,
-   timeout);
-   if (status > 0)
-   enable_irq(client->irq);
-
-   return status;
-} /* wait_for_interrupt_serirq_timeout() */
-
-static int wait_for_serirq_timeout(struct tpm_chip *chip, bool condition,
-unsigned long timeout)
-{
-   int status = 2;
-   struct tpm_stm_dev *tpm_dev;
-
-   tpm_dev = (struct tpm_stm_dev *)TPM_VPRIV(chip);
-
-   status = _wait_for_interrupt_serirq_timeout(chip, timeout);
-   if (!status) {
-   status = -EBUSY;
-   } else {
-   clear_interruption(tpm_dev);
-   if (condition)
-   status = 1;
-   }
-   return status;
-} /* wait_for_serirq_timeout() */
-
-/*
  * tpm_stm_i2c_cancel, cancel is not implemented.
  * @param: chip, the tpm_chip description as specified in driver/char/tpm/tpm.h
  */
@@ -242,8 +200,6 @@ static void tpm_stm_i2c_cancel(struct tpm_chip *chip)
 
data = TPM_STS_COMMAND_READY;
I2C_WRITE_DATA(tpm_dev, TPM_STS, &data, 1);
-   if (chip->vendor.irq)
-   wait_for_serirq_timeout(chip, 1, chip->vendor.timeout_a);
 } /* tpm_stm_i2c_cancel() */
 
 /*
@@ -298,30 +254,24 @@ static int request_locality(struct tpm_chip *chip)
struct tpm_stm_dev *tpm_dev;
u8 data;
 
-   tpm_dev = (struct tpm_stm_dev *)TPM_VPRIV(chip);
-
if (check_locality(chip) == chip->vendor.locality)
return chip->vendor.locality;
 
+   tpm_dev = (struct tpm_stm_dev *)TPM_VPRIV(chip);
+
data = TPM_ACCESS_REQUEST_USE;
r = I2C_WRITE_DATA(tpm_dev, TPM_ACCESS, &data, 1);
if (r < 0)
goto end;
 
-   if (chip->vendor.irq) {
-   r = wait_for_serirq_timeout(chip, (check_locality
-  (chip) >= 0),
- chip->vendor.timeout_a);
-   if (r > 0)
+   stop = jiffies + chip->vendor.timeout_a;
+
+   /* Request locality is usually effective after the request */
+   do {
+   if (check_locality(chip) >= 0)
return chip->vendor.locality;
-   } else {
-   stop = jiffies + chip->vendor.timeout_a;
-   do {
-   if (check_locality(chip) >= 0)
-   return chip->vendor.locality;
-   msleep(TPM_TIMEOUT);
-   } while (time_before(jiffies, stop));
-   }
+   msleep(TPM_TIMEOUT);
+   } while (time_before(jiffies, stop));
r = -EACCES;
 end:
return r;
@@ -379,36 

[PATCH v4 09/15] tpm/tpm_i2c_stm_st33/dts/st33zp24_i2c: Add DTS Documentation

[Christophe Ricard]

st33zp24 tpm can be seen as a trivial i2c device as other i2c tpm.
However several other properties needs to be documented such as lpcpd.

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 .../devicetree/bindings/security/tpm/st33zp24.txt  | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/st33zp24.txt

diff --git a/Documentation/devicetree/bindings/security/tpm/st33zp24.txt 
b/Documentation/devicetree/bindings/security/tpm/st33zp24.txt
new file mode 100644
index 000..eb48222
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/st33zp24.txt
@@ -0,0 +1,36 @@
+* STMicroelectronics SAS. ST33ZP24 TPM SoC
+
+Required properties:
+- compatible: Should be "st,st33zp24_i2c".
+- clock-frequency: I²C work frequency.
+- reg: address on the bus
+
+Optional ST33ZP24 Properties:
+- interrupt-parent: phandle for the interrupt gpio controller
+- interrupts: GPIO interrupt to which the chip is connected
+- lpcpd-gpios: Output GPIO pin used for ST33ZP24 power management D1/D2 state.
+If set vps must present when the platform is going into sleep/hibernate mode.
+
+Optional SoC Specific Properties:
+- pinctrl-names: Contains only one value - "default".
+- pintctrl-0: Specifies the pin control groups used for this controller.
+
+Example (for ARM-based BeagleBoard xM with ST33ZP24 on I2C2):
+
+&i2c2 {
+
+status = "okay";
+
+st33zp24: st33zp24@13 {
+
+compatible = "st,st33zp24_i2c";
+
+reg = <0x013>;
+clock-frequency = <40>;
+
+interrupt-parent = <&gpio5>;
+interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
+
+lpcpd-gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>;
+};
+};
-- 
1.9.1

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

[PATCH v4 10/15] tpm/tpm_i2c_stm_st33: Few code cleanup

[Christophe Ricard]

Cleanup code indentation, braces, test variable when NULL.

Reviewed-By: Jason Gunthorpe 
Signed-off-by: Christophe Ricard 
---
 drivers/char/tpm/tpm_i2c_stm_st33.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c 
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index 7339e84..54d1728 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -27,7 +27,7 @@
  *
  * @Synopsis:
  * 09/15/2010: First shot driver tpm_tis driver for
-lpc is used as model.
+ *  lpc is used as model.
  */
 
 #include 
@@ -394,7 +394,7 @@ static int wait_for_stat(struct tpm_chip *chip, u8 mask, 
unsigned long timeout,
long r;
u8 status;
 
-if (chip->vendor.irq) {
+   if (chip->vendor.irq) {
r = wait_for_serirq_timeout(chip, ((tpm_stm_i2c_status
(chip) & mask) ==
   mask), timeout);
@@ -430,8 +430,7 @@ static int recv_data(struct tpm_chip *chip, u8 *buf, size_t 
count)
   wait_for_stat(chip,
 TPM_STS_DATA_AVAIL | TPM_STS_VALID,
 chip->vendor.timeout_c,
-&chip->vendor.read_queue)
-  == 0) {
+&chip->vendor.read_queue) == 0) {
burstcnt = get_burstcount(chip);
if (burstcnt < 0)
return burstcnt;
@@ -483,7 +482,7 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned 
char *buf,
struct i2c_client *client;
struct tpm_stm_dev *tpm_dev;
 
-   if (chip == NULL)
+   if (!chip)
return -EBUSY;
if (len < TPM_HEADER_SIZE)
return -EBUSY;
@@ -560,7 +559,7 @@ static int tpm_stm_i2c_recv(struct tpm_chip *chip, unsigned 
char *buf,
int size = 0;
int expected;
 
-   if (chip == NULL)
+   if (!chip)
return -EBUSY;
 
if (count < TPM_HEADER_SIZE) {
@@ -581,7 +580,7 @@ static int tpm_stm_i2c_recv(struct tpm_chip *chip, unsigned 
char *buf,
}
 
size += recv_data(chip, &buf[TPM_HEADER_SIZE],
-   expected - TPM_HEADER_SIZE);
+   expected - TPM_HEADER_SIZE);
if (size < expected) {
dev_err(chip->dev, "Unable to read remainder of result\n");
size = -ETIME;
@@ -663,9 +662,9 @@ static int tpm_stm_i2c_request_resources(struct i2c_client 
*client,
int r;
 
pdata = client->dev.platform_data;
-   if (pdata == NULL) {
-   pr_err("No platform data\n");
-   return -EINVAL;
+   if (!pdata) {
+   dev_err(chip->dev, "No platform data\n");
+   return -ENODEV;
}
 
/* store for late use */
@@ -695,13 +694,13 @@ static int
 tpm_stm_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id)
 {
int r;
-   u8 intmask;
+   u8 intmask = 0;
struct tpm_chip *chip;
struct st33zp24_platform_data *platform_data;
struct tpm_stm_dev *tpm_dev;
 
-   if (client == NULL) {
-   pr_info("%s: i2c client is NULL. Device not accessible.\n",
+   if (!client) {
+   dev_info(chip->dev, "%s: i2c client is NULL. Device not 
accessible.\n",
__func__);
return -ENODEV;
}
@@ -804,7 +803,7 @@ _tpm_clean_answer:
 /*
  * tpm_stm_i2c_remove remove the TPM device
  * @param: client, the i2c_client drescription (TPM I2C description).
-   clear_bit(0, &chip->is_open);
+ * clear_bit(0, &chip->is_open);
  * @return: 0 in case of success.
  */
 static int tpm_stm_i2c_remove(struct i2c_client *client)
@@ -834,6 +833,7 @@ static int tpm_stm_i2c_pm_suspend(struct device *dev)
gpio_set_value(pin_infos->io_lpcpd, 0);
else
r = tpm_pm_suspend(dev);
+
return r;
 } /* tpm_stm_i2c_suspend() */
 
@@ -868,6 +868,7 @@ static const struct i2c_device_id tpm_stm_i2c_id[] = {
{TPM_ST33_I2C, 0},
{}
 };
+MODULE_DEVICE_TABLE(i2c, tpm_stm_i2c_id);
 
 #ifdef CONFIG_OF
 static const struct of_device_id of_st33zp24_i2c_match[] = {
@@ -877,7 +878,6 @@ static const struct of_device_id of_st33zp24_i2c_match[] = {
 MODULE_DEVICE_TABLE(of, of_st33zp24_i2c_match);
 #endif
 
-MODULE_DEVICE_TABLE(i2c, tpm_stm_i2c_id);
 static SIMPLE_DEV_PM_OPS(tpm_stm_i2c_ops, tpm_stm_i2c_pm_suspend,
tpm_stm_i2c_pm_resume);
 static struct i2c_driver tpm_stm_i2c_driver = {
@@ -886,7 +886,7 @@ static struct i2c_driver tpm_stm_i2c_driver = {
.name = TPM_ST33_I2C,
.pm = &tpm_stm_i2c_ops,
.of_match_table = of_match_ptr(of_st33zp24_i2c_match),
-  },
+   },
.p

Re: [PATCH 1/2] misc: Add Wi2Wi w2sc0004 gps driver

[Dr. H. Nikolaus Schaller]

Hi,

Am 19.10.2014 um 21:51 schrieb Arnd Bergmann :

> On Thursday 16 October 2014 22:26:22 Marek Belisko wrote:
>> This is a driver for the Wi2Wi GPS modules connected through an UART.
>> The tricky part is that the module is turned on or off by an impulse
>> on the control line - but it is only possible to get the real state by 
>> monitoring
>> the UART RX input. Since the kernel can't know in which status the module
>> is brought e.g. by a boot loader or after suspend, we need some logic to 
>> handle
>> this.
>> 
>> The driver allows two different methods to enable (and power up) GPS:
>> a) through rfkill
>> b) as a GPIO
>> 
>> The GPIO enable can be plumbed to other drivers that expect to be able to 
>> control
>> a GPIO. On the GTA04 board this is the DTR-gpio of the connected UART so that
>> opening the UART device enables the receiver and closing it shuts the 
>> receiver down.
>> 
>> Original implementation by Neil Brown, fixes + DT bindings by H. Nikolaus 
>> Schaller
> 
> I’m not sure if this is a good way to model the device.

It is the easiest way we have found after ca. 2 years of working on it :)

> You say that it's
> connected to a UART, but the code itself has no reference to the tty layer
> at all.

Yes.

> I assume the actual driver is in user space and it would open the
> UART and this control device as separate instances handles and then try
> to coordinate them. Is that right?

Yes, it is called gpsd.

> 
> What is the protocol for the GPS driver itself? Is it standardized?

Yes, NMEA records. Like most GPS receivers provide them.

> Would it help to have a TTY line discipline for the GPS mode instead
> so the power management and startup could be integrated into the serial
> port management instead?

I don’t think line disciplines (as far as I understand them) are helpful and
this chip is not special at all regarding the serial interface data. So it 
needs no
“GPS mode”.

It is very similar to connecting some external handheld GPS receiver by a
RS232 cable or RS232-USB adapter. Or GPS “mouse” receivers through
bluetooth.

They all create/show some /dev/tty that you simply open/read/close. And
there is no special processing of the serial data involved.

The only thing this driver needs to solve is to properly power up/down
the chip on demand.

The DTR line of the tty can enable/disable power of a connected device
(being an external modem or this GPS chip). This is what we have made
the driver compatible to by providing a virtual GPIO to enable/disable.

This is done by a patch to the tty driver that already was in the kernel
but removed in 3.15 because the w2sg driver wasn’t submitted at that
time.

Commit: 985bfd54c826c0ba873ca0adfd5589263e0c6ee2

Basically, if our CPU would have a real RS232 interface and we would
put the chip into an external device, it should look exactly the same if
we look at the serial interface part. Since soldering it on the same PCB
or connecting through a connector should not need different serial drivers.
Just different device tree files.

Therefore we have decided not to touch any serial driver code at all,
because it is not needed (except allowing DTR to control some GPIO)
and keeps it simple and manageable.

BR,
Nikolaus


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

Re: [PATCH v3] iio: iadc: Qualcomm SPMI PMIC current ADC driver

[Hartmut Knaack]

Ivan T. Ivanov schrieb am 01.10.2014 18:14:
> The current ADC is peripheral of Qualcomm SPMI PMIC chips. It has
> 16 bits resolution and register space inside PMIC accessible across
> SPMI bus.
> 
> The driver registers itself through IIO interface.
> 
Hi, I spotted some issues, see inline.
> Signed-off-by: Ivan T. Ivanov 
> ---
> 
> Changes since v2:
> 
> - DT bindings fixed according comments.
> - IADC driver now register 2 channels instead of just one.
> - Fixed sense resistor Ohms dimensions. It is supposed that
>   values are around 0.010 Ohms not 10 Mega Ohms.
> - Removed direct driver access to registers in Battery Monitor 
>   peripheral address space. Which will impact correct internal
>   sense resistor calculation on some variants and vendors of
>   pm8110 and pm8226. This could be added once we figured out how
>   to pass/read PMIC device version from sub-function drivers.
> 
> v2: http://www.gossamer-threads.com/lists/linux/kernel/2016613
> 
>  .../devicetree/bindings/iio/adc/qcom,spmi-iadc.txt |  46 ++
>  drivers/iio/adc/Kconfig|  11 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/qcom-spmi-iadc.c   | 626 
> +
>  4 files changed, 684 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
>  create mode 100644 drivers/iio/adc/qcom-spmi-iadc.c
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt 
> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> new file mode 100644
> index 000..833afd6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> @@ -0,0 +1,46 @@
> +Qualcomm's SPMI PMIC current ADC
> +
> +QPNP PMIC current ADC (IADC) provides interface to clients to read current.
> +A 16 bit ADC is used for current measurements. IADC can measure the current
> +through an external resistor(channel 1)or internal(built-in) resistor
There are some whitespaces missing around the parenthesis.
> +(channel 0). When using an external resistor it is to be described by
> +qcom,external-resistor-micro-ohms property.
> +
> +IADC node:
> +
> +- compatible:
> +Usage: required
> +Value type: 
> +Definition: Should contain "qcom,spmi-iadc".
> +
> +- reg:
> +Usage: required
> +Value type: 
> +Definition: IADC base address and length in the SPMI PMIC register map
> +
> +- interrupts:
> +Usage: optional
> +Value type: 
> +Definition: End of ADC conversion.
> +
> +- qcom,external-resistor-micro-ohms:
> +Usage: optional
> +Value type: 
> +Definition: Sense resister value in micro Ohm.
> +If not defined value of 1 micro Ohms will be used.
> +
> +Example:
> + /* IADC node */
> + pmic_iadc: iadc@3600 {
> + compatible = "qcom,spmi-iadc";
> + reg = <0x3600 0x100>;
> + interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
> + qcom,external-resistor-micro-ohms = <1>;
> + #io-channel-cells  = <1>;
> + };
> +
> + /* IIO client node */
> + bat {
> + io-channels = <&pmic_iadc>;
> + io-channel-names = "iadc 0";
> + };
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 11b048a..ee1ad5b 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -206,6 +206,17 @@ config NAU7802
> To compile this driver as a module, choose M here: the
> module will be called nau7802.
>  
> +config QCOM_SPMI_IADC
> + tristate "Qualcomm SPMI PMIC current ADC"
> + depends on SPMI
> + select REGMAP_SPMI
> + help
> +   This is the IIO Current ADC driver for Qualcomm QPNP IADC Chip.
> +
> +   The driver supports single mode operation to read from two
> +   channels (external or internal). Hardware have additional
> +   channels internally used for gain and offset calibration.
To compile this driver as a module, choose M here: the module will be called 
qcom-spmi-iadc.
> +
>  config TI_ADC081C
>   tristate "Texas Instruments ADC081C021/027"
>   depends on I2C
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index ad81b51..c790543 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_VF610_ADC) += vf610_adc.o
>  obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
>  xilinx-xadc-y := xilinx-xadc-core.o xilinx-xadc-events.o
>  obj-$(CONFIG_XILINX_XADC) += xilinx-xadc.o
> +obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
Please sort in your entry in alphabetic order.
> diff --git a/drivers/iio/adc/qcom-spmi-iadc.c 
> b/drivers/iio/adc/qcom-spmi-iadc.c
> new file mode 100644
> index 000..f4328f2
> --- /dev/null
> +++ b/drivers/iio/adc/qcom-spmi-iadc.c
> @@ -0,0 +1,626 @@
> +/*
> + * Copyright (c) 2012-2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribu

Re: [PATCH 1/2] misc: Add Wi2Wi w2sc0004 gps driver

[Arnd Bergmann]

On Thursday 16 October 2014 22:26:22 Marek Belisko wrote:
> This is a driver for the Wi2Wi GPS modules connected through an UART.
> The tricky part is that the module is turned on or off by an impulse
> on the control line - but it is only possible to get the real state by 
> monitoring
> the UART RX input. Since the kernel can't know in which status the module
> is brought e.g. by a boot loader or after suspend, we need some logic to 
> handle
> this.
> 
> The driver allows two different methods to enable (and power up) GPS:
> a) through rfkill
> b) as a GPIO
> 
> The GPIO enable can be plumbed to other drivers that expect to be able to 
> control
> a GPIO. On the GTA04 board this is the DTR-gpio of the connected UART so that
> opening the UART device enables the receiver and closing it shuts the 
> receiver down.
> 
> Original implementation by Neil Brown, fixes + DT bindings by H. Nikolaus 
> Schaller

I'm not sure if this is a good way to model the device. You say that it's
connected to a UART, but the code itself has no reference to the tty layer
at all. I assume the actual driver is in user space and it would open the
UART and this control device as separate instances handles and then try
to coordinate them. Is that right?

What is the protocol for the GPS driver itself? Is it standardized?
Would it help to have a TTY line discipline for the GPS mode instead
so the power management and startup could be integrated into the serial
port management instead?

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

Re: [PATCHv5 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Arnd Bergmann]

On Sunday 19 October 2014 09:17:46 Shawn Guo wrote:
> > diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> > new file mode 100644
> > index 000..5075c18
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/ls1021a.dtsi
> > @@ -0,0 +1,405 @@
> > +/*
> > + * Copyright 2013-2014 Freescale Semiconductor, Inc.
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + *  a) This library 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; either version 2 of
> > + * the License, or (at your option) any later version.
> > + *
> > + * This library 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.
> > + *
> > + * You should have received a copy of the GNU General Public
> > + * License along with this library; if not, write to the Free
> > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> > + * MA 02110-1301 USA
> > + *
> > + * Or, alternatively,
> > + *
> > + *  b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> 
> DT maintainers,
> 
> I would like to confirm this is a appropriate copyright for device tree
> sources, as it sets the example how we should migrate from the existing
> GPL.  If we merge it, I assume that a lot of future files will likely
> follow the example.

The license is fine as far as I can tell, but the first half mentions
'library' three times, and that should probably be changed to 'file'.

The Allwinner dts files had the same text and are now changing it to
say 'file'.

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

RE: [PATCH v2 00/11] ARM: dts: zynq: Prepare Parallella

[Soren Brinkmann]

Sorry, for top-posting, but I currently just have Outlook webmail.
The cause for this issue is relatively easily identified. The ethernet drivers 
sets the Ethernet clock according to the negotioated link speed. For this 
adjustment a 6-bit divider in the clock path is used. In this case, it seems, 
the input to the 6-bit divider doesn't allow generating the full range of 
required frequencies for all supported link speeds.

I guess this could be solved in multiple ways.
1. Disable 1G mode/auto negotiation, the other modes are probably fine (yeah, 
not a solution, but might give you a working ethernet link)
2. Ensure the divider input allows to generate all required frequencies. This 
essentially means to go back into Xilinx tools and play around with the 
clock/PLL setup and re-generating a bootloader that sets things up with the 
updated values.
3. Support to run-time-adust the PLLs in Zynq. This is definitely the most 
complex one. I never seriously pursued this, since it seemed close to 
impossible to change the PLLs at run-time without crashing pretty much every 
downstream user except for the one that requested the frequency change. And 
even if every driver would be able to handle such a change, I could imagine 
that frequency constraints from  all the drivers together would still prevent 
any change.

Thanks,
Sören


From: devicetree-ow...@vger.kernel.org [devicetree-ow...@vger.kernel.org] on 
behalf of Olof Johansson [o...@lixom.net]
Sent: Friday, October 17, 2014 9:28 PM
To: Andreas Färber
Cc: Michal Simek; Andreas Olofsson; Matteo Vit; Sean Rickerd; 
devicetree@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
linux-ker...@vger.kernel.org; Punnaiah Choudary Kalluri; Lars-Peter Clausen
Subject: Re: [PATCH v2 00/11] ARM: dts: zynq: Prepare Parallella

Hi Andreas,

On Thu, Jul 24, 2014 at 4:00 PM, Andreas Färber  wrote:
> Hello,
>
> This patch series adds an initial device tree for the Parallella board.
> UART, SD card, Ethernet are enabled.
> Not yet enabled are HDMI, QSPI flash and 2x USB.

Andreas (Olofsson) kindly sent me a board, and I added it to the boot
farm today, it'll be included in boot reports from here on.

I did a test run with yesterday's -next It looks like networking isn't
working there at the moment, clock related. Same happens with 3.17 and
latest mainline, config multi_v7_defconfig:

[WARN] [7.943648] macb e000b000.ethernet eth0: unable to generate
target frequency: 12500 Hz
[WARN] [   10.948681] macb e000b000.ethernet eth0: unable to generate
target frequency: 12500 Hz

Full boot log at:

http://arm-soc.lixom.net/bootlogs/misc/next-20141017/parallella-arm-multi_v7_defconfig.html

I'll be happy to try things, but I'm a bit short on cycles to debug
myself. Should hopefully be easy to reproduce.


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


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

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

[PATCH v5] crypto: Add Allwinner Security System crypto accelerator

[LABBE Corentin]

Hello

This is the driver for the Security System included in Allwinner SoC A20.
The Security System (SS for short) is a hardware cryptographic accelerator that 
support AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on others Allwinner SoC: 
- A10s, A33 and A31 diagram speak about it with precisions 
(AES/DES/3DES/Md5/SHA1/PRNG)
- A10 and A13 manual give the same datasheet for SS than A20
- A23 speak about a security system but without precisions
- A80 datasheet speak about a security system with more functions 
(SHA224/SHA256/RSA/CRC) but without precisions
But I do not have access on any of those hardware, tests are welcome.

This driver currently supports:
- MD5 and SHA1 hash algorithms
- AES block cipher in CBC mode with 128/196/256bits keys.
- DES and 3DES block cipher in CBC mode
The driver exposes all those algorithms through the kernel cryptographic API.

The driver support only CPU driven (aka poll mode) transfer mode since the DMA 
engine of the A20 does not have a mainline driver yet.

Changes since v4:
- Rework all mutex path
- Use ahash_request_ctx() in hash functions
- Major rework of hash functions for solving mutex problems
- Split sunxi_req_ctx in two since ciphers now use struct sunxi_tfm_ctx
- Hash functions now test FIFO space register

Changes since v3:
- Remove all algorithms options from Kconfig, so now only one module is used
- Add the sunxi_ss_cipher function to unify mode calculation
- Remove the sunxi_cipher_exit empty function
- Add some missing mutex_unlock()
- Drop PRNG support, I wait for more comment on its results before re-enabling 
it.

Changes since v2:
- Fix Makefile and Kconfig for static kernel.

Changes since v1:
- annotate ss->base as __iomem
- regroup all mutex in the ss_ctx structure
- splited driver in 7 modules (core md5 sha1 aes des 3des prng) in sunxi-ss 
directory
- use dev_exit_p() for .remove
- added missing CRYPTO_BLKCIPHER dep in Kconfig
- use ahash instead of shash
- use ablkcipher instead of blkcipher
- use crypto_rng_ctx instead of crypto_tfm_ctx
- set seed as an u32
- drop useless comment decoration
- drop useless debug
- ss_ctx is now a static pointer and whole structure being allocated
- fix the platform_get_resource/devm_ioremap_resource pattern
- invert getting die id and configuring clock
- set clock value as a const unsigned long
- add MODULE_ALIAS
- use define names more consistency (SS_xxx)
- fix PRNG errors
- respell SS to Security System in DT documentation


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

[PATCH v5 3/4] MAINTAINERS: Add myself as maintainer of Allwinner Security System

[LABBE Corentin]

Signed-off-by: LABBE Corentin 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 33c0d43..8ee4ac0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10425,6 +10425,12 @@ L: linux...@kvack.org
 S: Maintained
 F: mm/zswap.c
 
+ALLWINNER SECURITY SYSTEM
+M: Corentin Labbe 
+L: linux-cry...@vger.kernel.org
+S: Maintained
+F: drivers/crypto/sunxi-ss/
+
 THE REST
 M: Linus Torvalds 
 L: linux-ker...@vger.kernel.org
-- 
2.0.4

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

[PATCH v5 1/4] ARM: sun7i: dt: Add Security System to A20 SoC DTS

[LABBE Corentin]

The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.

This patch enable the Security System on the Allwinner A20 SoC Device-tree.

Signed-off-by: LABBE Corentin 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 82097c9..ebcdc76 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -577,6 +577,14 @@
status = "disabled";
};
 
+   crypto: crypto-engine@01c15000 {
+   compatible = "allwinner,sun7i-a20-crypto";
+   reg = <0x01c15000 0x1000>;
+   interrupts = <0 86 4>;
+   clocks = <&ahb_gates 5>, <&ss_clk>;
+   clock-names = "ahb", "mod";
+   };
+
spi2: spi@01c17000 {
compatible = "allwinner,sun4i-a10-spi";
reg = <0x01c17000 0x1000>;
-- 
2.0.4

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

[PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator

[LABBE Corentin]

Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support 
AES/MD5/SHA1/DES/3DES/PRNG algorithms.

Signed-off-by: LABBE Corentin 
---
 drivers/crypto/Kconfig|  17 ++
 drivers/crypto/Makefile   |   1 +
 drivers/crypto/sunxi-ss/Makefile  |   2 +
 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 489 ++
 drivers/crypto/sunxi-ss/sunxi-ss-core.c   | 318 +++
 drivers/crypto/sunxi-ss/sunxi-ss-hash.c   | 445 +++
 drivers/crypto/sunxi-ss/sunxi-ss.h| 193 
 7 files changed, 1465 insertions(+)
 create mode 100644 drivers/crypto/sunxi-ss/Makefile
 create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
 create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-core.c
 create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c
 create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2fb0fdf..9ba9759 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -436,4 +436,21 @@ config CRYPTO_DEV_QCE
  hardware. To compile this driver as a module, choose M here. The
  module will be called qcrypto.
 
+config CRYPTO_DEV_SUNXI_SS
+   tristate "Support for Allwinner Security System cryptographic 
accelerator"
+   depends on ARCH_SUNXI
+   select CRYPTO_MD5
+   select CRYPTO_SHA1
+   select CRYPTO_AES
+   select CRYPTO_DES
+   select CRYPTO_BLKCIPHER
+   help
+ Some Allwinner SoC have a crypto accelerator named
+ Security System. Select this if you want to use it.
+ The Security System handle AES/DES/3DES ciphers in CBC mode
+ and SHA1 and MD5 hash algorithms.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sunxi-ss.
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 3924f93..856545c 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
 obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
 obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
 obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss/
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
new file mode 100644
index 000..8bb287d
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o
+sunxi-ss-y += sunxi-ss-core.o sunxi-ss-hash.o sunxi-ss-cipher.o
diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c 
b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
new file mode 100644
index 000..8d0416e
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
@@ -0,0 +1,489 @@
+/*
+ * sunxi-ss-cipher.c - hardware cryptographic accelerator for Allwinner A20 SoC
+ *
+ * Copyright (C) 2013-2014 Corentin LABBE 
+ *
+ * This file add support for AES cipher with 128,192,256 bits
+ * keysize in CBC mode.
+ * Add support also for DES and 3DES in CBC mode.
+ *
+ * You could find the datasheet in Documentation/arm/sunxi/README
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include "sunxi-ss.h"
+
+extern struct sunxi_ss_ctx *ss;
+
+static int sunxi_ss_cipher(struct ablkcipher_request *areq, u32 mode)
+{
+   struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
+   struct sunxi_tfm_ctx *op = crypto_ablkcipher_ctx(tfm);
+   const char *cipher_type;
+
+   if (areq->nbytes == 0)
+   return 0;
+
+   if (areq->info == NULL) {
+   dev_err(ss->dev, "ERROR: Empty IV\n");
+   return -EINVAL;
+   }
+
+   if (areq->src == NULL || areq->dst == NULL) {
+   dev_err(ss->dev, "ERROR: Some SGs are NULL\n");
+   return -EINVAL;
+   }
+
+   cipher_type = crypto_tfm_alg_name(crypto_ablkcipher_tfm(tfm));
+
+   if (strcmp("cbc(aes)", cipher_type) == 0) {
+   mode |= SS_OP_AES | SS_CBC | SS_ENABLED | op->keymode;
+   return sunxi_ss_aes_poll(areq, mode);
+   }
+
+   if (strcmp("cbc(des)", cipher_type) == 0) {
+   mode |= SS_OP_DES | SS_CBC | SS_ENABLED | op->keymode;
+   return sunxi_ss_des_poll(areq, mode);
+   }
+
+   if (strcmp("cbc(des3_ede)", cipher_type) == 0) {
+   mode |= SS_OP_3DES | SS_CBC | SS_ENABLED | op->keymode;
+   return sunxi_ss_des_poll(areq, mode);
+   }
+
+   dev_err(ss->dev, "ERROR: Cipher %s not handled\n", cipher_type);
+   return -EINVAL;
+}
+
+int sunxi_ss_cipher_encrypt(struct ablkcipher_request *areq)
+{
+   return sunxi_ss_cipher(areq, SS_ENCRYP

[PATCH v5 2/4] ARM: sunxi: dt: Add DT bindings documentation for SUNXI Security System

[LABBE Corentin]

This patch adds documentation for Device-Tree bindings for the Security System 
cryptographic accelerator driver.

Signed-off-by: LABBE Corentin 
---
 Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/sunxi-ss.txt

diff --git a/Documentation/devicetree/bindings/crypto/sunxi-ss.txt 
b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt
new file mode 100644
index 000..a566803
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt
@@ -0,0 +1,9 @@
+* Allwinner Security System found on A20 SoC
+
+Required properties:
+- compatible : Should be "allwinner,sun7i-a20-crypto".
+- reg: Should contain the Security System register location and length.
+- interrupts: Should contain the IRQ line for the Security System.
+- clocks : A phandle to the functional clock node of the Security System module
+- clock-names : Name of the functional clock, should be "ahb" and "mod".
+
-- 
2.0.4

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

[PATCH] of/fdt: Add extern prototype for early_init_dt_scan_chosen_serial()

[Kevin Cernekee]

The original commit that introduced this function (fb11ffe74c794a)
indicated that calling it from the architecture code was one possible
use case.  Let's declare it in of_fdt.h to make it a public API.

Signed-off-by: Kevin Cernekee 
---
 include/linux/of_fdt.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 0ff360d..5d233df 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -12,6 +12,7 @@
 #ifndef _LINUX_OF_FDT_H
 #define _LINUX_OF_FDT_H
 
+#include 
 #include 
 #include 
 
@@ -87,6 +88,13 @@ extern void early_init_devtree(void *);
 extern void early_get_first_memblock_info(void *, phys_addr_t *);
 extern u64 fdt_translate_address(const void *blob, int node_offset);
 extern void of_fdt_limit_memory(int limit);
+
+#if defined(CONFIG_SERIAL_EARLYCON)
+extern int early_init_dt_scan_chosen_serial(void);
+#else
+static inline int early_init_dt_scan_chosen_serial(void) { return -ENOENT; }
+#endif
+
 #else /* CONFIG_OF_FLATTREE */
 static inline void early_init_fdt_scan_reserved_mem(void) {}
 static inline const char *of_flat_dt_get_machine_name(void) { return NULL; }
-- 
2.1.1

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