Re: [PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-03-01 Thread Hans de Goede

Hi,

On 01-03-18 10:32, Andy Shevchenko wrote:

On Thu, Mar 1, 2018 at 9:28 AM, Heikki Krogerus
 wrote:

Hi,

On Thu, Mar 01, 2018 at 12:56:57AM +, Jun Li wrote:

+struct device *device_find_connection(struct device *dev, const char
+*con_id) {
+   return __device_find_connection(dev, con_id, generic_match, NULL); }


-   return __device_find_connection(dev, con_id, generic_match, NULL);
+   return __device_find_connection(dev, con_id, NULL, generic_match);


Good catch!


It seems I proposed to put function first parameter followed by opaque
data pointer for it.
In that case it would be exactly like now.


Yes, but as mentioned I decided to keep it as is, so this is really a bug,
will fix for v6.

Regards,

Hans


Re: [PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-03-01 Thread Hans de Goede

Hi,

On 01-03-18 10:32, Andy Shevchenko wrote:

On Thu, Mar 1, 2018 at 9:28 AM, Heikki Krogerus
 wrote:

Hi,

On Thu, Mar 01, 2018 at 12:56:57AM +, Jun Li wrote:

+struct device *device_find_connection(struct device *dev, const char
+*con_id) {
+   return __device_find_connection(dev, con_id, generic_match, NULL); }


-   return __device_find_connection(dev, con_id, generic_match, NULL);
+   return __device_find_connection(dev, con_id, NULL, generic_match);


Good catch!


It seems I proposed to put function first parameter followed by opaque
data pointer for it.
In that case it would be exactly like now.


Yes, but as mentioned I decided to keep it as is, so this is really a bug,
will fix for v6.

Regards,

Hans


Re: [PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-03-01 Thread Andy Shevchenko
On Thu, Mar 1, 2018 at 9:28 AM, Heikki Krogerus
 wrote:
> Hi,
>
> On Thu, Mar 01, 2018 at 12:56:57AM +, Jun Li wrote:
>> > +struct device *device_find_connection(struct device *dev, const char
>> > +*con_id) {
>> > +   return __device_find_connection(dev, con_id, generic_match, NULL); }
>>
>> -   return __device_find_connection(dev, con_id, generic_match, NULL);
>> +   return __device_find_connection(dev, con_id, NULL, generic_match);
>
> Good catch!

It seems I proposed to put function first parameter followed by opaque
data pointer for it.
In that case it would be exactly like now.

Though, I didn't check if the parameter ordering was changed in the prototype.

-- 
With Best Regards,
Andy Shevchenko


Re: [PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-03-01 Thread Andy Shevchenko
On Thu, Mar 1, 2018 at 9:28 AM, Heikki Krogerus
 wrote:
> Hi,
>
> On Thu, Mar 01, 2018 at 12:56:57AM +, Jun Li wrote:
>> > +struct device *device_find_connection(struct device *dev, const char
>> > +*con_id) {
>> > +   return __device_find_connection(dev, con_id, generic_match, NULL); }
>>
>> -   return __device_find_connection(dev, con_id, generic_match, NULL);
>> +   return __device_find_connection(dev, con_id, NULL, generic_match);
>
> Good catch!

It seems I proposed to put function first parameter followed by opaque
data pointer for it.
In that case it would be exactly like now.

Though, I didn't check if the parameter ordering was changed in the prototype.

-- 
With Best Regards,
Andy Shevchenko


Re: [PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-02-28 Thread Heikki Krogerus
Hi,

On Thu, Mar 01, 2018 at 12:56:57AM +, Jun Li wrote:
> > +struct device *device_find_connection(struct device *dev, const char
> > +*con_id) {
> > +   return __device_find_connection(dev, con_id, generic_match, NULL); }
> 
> -   return __device_find_connection(dev, con_id, generic_match, NULL);
> +   return __device_find_connection(dev, con_id, NULL, generic_match);

Good catch!

Thanks,

-- 
heikki


Re: [PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-02-28 Thread Heikki Krogerus
Hi,

On Thu, Mar 01, 2018 at 12:56:57AM +, Jun Li wrote:
> > +struct device *device_find_connection(struct device *dev, const char
> > +*con_id) {
> > +   return __device_find_connection(dev, con_id, generic_match, NULL); }
> 
> -   return __device_find_connection(dev, con_id, generic_match, NULL);
> +   return __device_find_connection(dev, con_id, NULL, generic_match);

Good catch!

Thanks,

-- 
heikki


RE: [PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-02-28 Thread Jun Li
Hi,
> -Original Message-

> +struct device *device_find_connection(struct device *dev, const char
> +*con_id) {
> + return __device_find_connection(dev, con_id, generic_match, NULL); }

-   return __device_find_connection(dev, con_id, generic_match, NULL);
+   return __device_find_connection(dev, con_id, NULL, generic_match);

Jun Li
> +EXPORT_SYMBOL_GPL(device_find_connection);



RE: [PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-02-28 Thread Jun Li
Hi,
> -Original Message-

> +struct device *device_find_connection(struct device *dev, const char
> +*con_id) {
> + return __device_find_connection(dev, con_id, generic_match, NULL); }

-   return __device_find_connection(dev, con_id, generic_match, NULL);
+   return __device_find_connection(dev, con_id, NULL, generic_match);

Jun Li
> +EXPORT_SYMBOL_GPL(device_find_connection);



[PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-02-28 Thread Hans de Goede
From: Heikki Krogerus 

Several frameworks - clk, gpio, phy, pmw, etc. - maintain
lookup tables for describing connections and provide custom
API for handling them. This introduces a single generic
lookup table and API for the connections.

The motivation for this commit is centralizing the
connection lookup, but the goal is to ultimately extract the
connection descriptions also from firmware by using the
fwnode_graph_* functions and other mechanisms that are
available.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v5:
-Add missing documentation for @list struct devcon member

Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Various spelling and gramar fixes in the docs pointed out by Randy Dunlap

Changes in v2:
-Add a (struct devcon) cast to the DEVCON() macro
---
 Documentation/driver-api/device_connection.rst |  43 
 drivers/base/Makefile  |   3 +-
 drivers/base/devcon.c  | 139 +
 include/linux/connection.h |  34 ++
 4 files changed, 218 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/driver-api/device_connection.rst
 create mode 100644 drivers/base/devcon.c
 create mode 100644 include/linux/connection.h

diff --git a/Documentation/driver-api/device_connection.rst 
b/Documentation/driver-api/device_connection.rst
new file mode 100644
index ..64a3e5e9bb7c
--- /dev/null
+++ b/Documentation/driver-api/device_connection.rst
@@ -0,0 +1,43 @@
+==
+Device connections
+==
+
+Introduction
+
+
+Devices often have connections to other devices that are outside of the direct
+child/parent relationship. A serial or network communication controller, which
+could be a PCI device, may need to be able to get a reference to its PHY
+component, which could be attached for example to the I2C bus. Some device
+drivers need to be able to control the clocks or the GPIOs for their devices,
+and so on.
+
+Device connections are generic descriptions of any type of connection between
+two separate devices.
+
+Device connections alone do not create a dependency between the two devices.
+They are only descriptions which are not tied to either of the devices 
directly.
+A dependency between the two devices exists only if one of the two endpoint
+devices requests a reference to the other. The descriptions themselves can be
+defined in firmware (not yet supported) or they can be built-in.
+
+Usage
+-
+
+Device connections should exist before device ``->probe`` callback is called 
for
+either endpoint device in the description. If the connections are defined in
+firmware, this is not a problem. It should be considered if the connection
+descriptions are "built-in", and need to be added separately.
+
+The connection description consists of the names of the two devices with the
+connection, i.e. the endpoints, and unique identifier for the connection which
+is needed if there are multiple connections between the two devices.
+
+After a description exists, the devices in it can request reference to the 
other
+endpoint device, or they can request the description itself.
+
+API
+---
+
+.. kernel-doc:: drivers/base/devcon.c
+   : functions: __device_find_connection device_find_connection 
add_device_connection remove_device_connection
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index e32a52490051..12a7f64d35a9 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -5,7 +5,8 @@ obj-y   := component.o core.o bus.o dd.o 
syscore.o \
   driver.o class.o platform.o \
   cpu.o firmware.o init.o map.o devres.o \
   attribute_container.o transport_class.o \
-  topology.o container.o property.o cacheinfo.o
+  topology.o container.o property.o cacheinfo.o \
+  devcon.o
 obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
new file mode 100644
index ..1628dcb34709
--- /dev/null
+++ b/drivers/base/devcon.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Device connections
+ *
+ * Copyright (C) 2018 Intel Corporation
+ * Author: Heikki Krogerus 
+ */
+
+#include 
+#include 
+
+static DEFINE_MUTEX(devcon_lock);
+static LIST_HEAD(devcon_list);
+
+/**
+ * __device_find_connection - Find physical connection to a device
+ * @dev: Device with the connection
+ * @con_id: Identifier for the connection
+ * @data: Data for the match function
+ * @match: Function to check and convert the connection 

[PATCH v5 01/12] drivers: base: Unified device connection lookup

2018-02-28 Thread Hans de Goede
From: Heikki Krogerus 

Several frameworks - clk, gpio, phy, pmw, etc. - maintain
lookup tables for describing connections and provide custom
API for handling them. This introduces a single generic
lookup table and API for the connections.

The motivation for this commit is centralizing the
connection lookup, but the goal is to ultimately extract the
connection descriptions also from firmware by using the
fwnode_graph_* functions and other mechanisms that are
available.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v5:
-Add missing documentation for @list struct devcon member

Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Various spelling and gramar fixes in the docs pointed out by Randy Dunlap

Changes in v2:
-Add a (struct devcon) cast to the DEVCON() macro
---
 Documentation/driver-api/device_connection.rst |  43 
 drivers/base/Makefile  |   3 +-
 drivers/base/devcon.c  | 139 +
 include/linux/connection.h |  34 ++
 4 files changed, 218 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/driver-api/device_connection.rst
 create mode 100644 drivers/base/devcon.c
 create mode 100644 include/linux/connection.h

diff --git a/Documentation/driver-api/device_connection.rst 
b/Documentation/driver-api/device_connection.rst
new file mode 100644
index ..64a3e5e9bb7c
--- /dev/null
+++ b/Documentation/driver-api/device_connection.rst
@@ -0,0 +1,43 @@
+==
+Device connections
+==
+
+Introduction
+
+
+Devices often have connections to other devices that are outside of the direct
+child/parent relationship. A serial or network communication controller, which
+could be a PCI device, may need to be able to get a reference to its PHY
+component, which could be attached for example to the I2C bus. Some device
+drivers need to be able to control the clocks or the GPIOs for their devices,
+and so on.
+
+Device connections are generic descriptions of any type of connection between
+two separate devices.
+
+Device connections alone do not create a dependency between the two devices.
+They are only descriptions which are not tied to either of the devices 
directly.
+A dependency between the two devices exists only if one of the two endpoint
+devices requests a reference to the other. The descriptions themselves can be
+defined in firmware (not yet supported) or they can be built-in.
+
+Usage
+-
+
+Device connections should exist before device ``->probe`` callback is called 
for
+either endpoint device in the description. If the connections are defined in
+firmware, this is not a problem. It should be considered if the connection
+descriptions are "built-in", and need to be added separately.
+
+The connection description consists of the names of the two devices with the
+connection, i.e. the endpoints, and unique identifier for the connection which
+is needed if there are multiple connections between the two devices.
+
+After a description exists, the devices in it can request reference to the 
other
+endpoint device, or they can request the description itself.
+
+API
+---
+
+.. kernel-doc:: drivers/base/devcon.c
+   : functions: __device_find_connection device_find_connection 
add_device_connection remove_device_connection
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index e32a52490051..12a7f64d35a9 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -5,7 +5,8 @@ obj-y   := component.o core.o bus.o dd.o 
syscore.o \
   driver.o class.o platform.o \
   cpu.o firmware.o init.o map.o devres.o \
   attribute_container.o transport_class.o \
-  topology.o container.o property.o cacheinfo.o
+  topology.o container.o property.o cacheinfo.o \
+  devcon.o
 obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
new file mode 100644
index ..1628dcb34709
--- /dev/null
+++ b/drivers/base/devcon.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Device connections
+ *
+ * Copyright (C) 2018 Intel Corporation
+ * Author: Heikki Krogerus 
+ */
+
+#include 
+#include 
+
+static DEFINE_MUTEX(devcon_lock);
+static LIST_HEAD(devcon_list);
+
+/**
+ * __device_find_connection - Find physical connection to a device
+ * @dev: Device with the connection
+ * @con_id: Identifier for the connection
+ * @data: Data for the match function
+ * @match: Function to check and convert the connection description
+ *
+ * Find a connection with unique identifier @con_id between @dev and another
+ * device. @match will be used to convert the connection description to