mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Hans de Goede <hdegoede@redhat.com>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 01/12] drivers: base: Unified device connection lookup
Date: Sun, 25 Feb 2018 11:04:12 -0800	[thread overview]
Message-ID: <6d89fe84-7196-fe60-86d9-29b05fa97ad8@infradead.org> (raw)
In-Reply-To: <20180225152510.10159-2-hdegoede@redhat.com>

On 02/25/2018 07:24 AM, Hans de Goede wrote:
> From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> 
> 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 <heikki.krogerus@linux.intel.com>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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                     |  33 ++++++
>  4 files changed, 217 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 000000000000..d52604448356
> --- /dev/null
> +++ b/Documentation/driver-api/device_connection.rst
> @@ -0,0 +1,43 @@
> +==================
> +Device connections
> +==================
> +
> +Introduction
> +------------
> +
> +Devices have often connections to other devices that are out side of the direct

   Devices often have connections                       are outside of

> +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 to for example the I2C bus. Some device

                    could be attached for example to the I2C bus.

> +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 devices directly.

                                                           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 build-in.

                                                          built-in.

> +
> +Usage
> +-----
> +
> +Device connections should exist before device ``->probe`` callback is called for
> +either endpoint devices in the description. If the connections are defined in

                   device

> +firmware, this is not a problem. It should be considered if the connection
> +descriptions are "build-in", and need to be added separately.

                    "built-in",

> +
> +The connection description consist of the names of the two devices with the

                              consists

> +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 descriptions exist, the devices in it can request reference to the other

           description exists,

> +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/devcon.c b/drivers/base/devcon.c
> new file mode 100644
> index 000000000000..6f9e4f7280a5
> --- /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 <heikki.krogerus@linux.intel.com>
> + */
> +
> +#include <linux/connection.h>
> +#include <linux/device.h>
> +
> +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 an other

                                                                        another

> + * device. @match will be used to convert the connection description to data the
> + * caller is expecting to be returned.
> + */
> +void *__device_find_connection(struct device *dev, const char *con_id,
> +			       void *data,
> +			       void *(*match)(struct devcon *con, int ep,
> +					      void *data))
> +{
> +	const char *devname = dev_name(dev);
> +	struct devcon *con;
> +	void *ret = NULL;
> +	int ep;
> +
> +	if (!match)
> +		return NULL;
> +
> +	rcu_read_lock();
> +
> +	list_for_each_entry_rcu(con, &devcon_list, list) {
> +		ep = match_string(con->endpoint, 2, devname);
> +		if (ep < 0)
> +			continue;
> +
> +		if (con_id && strcmp(con->id, con_id))
> +			continue;
> +
> +		ret = match(con, !ep, data);
> +		if (ret)
> +			break;
> +	}
> +
> +	rcu_read_unlock();
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(__device_find_connection);
> +
> +#include <linux/platform_device.h>
> +#include <linux/spi/spi.h>
> +#include <linux/i2c.h>
> +#include <linux/pci.h>
> +
> +static struct bus_type *generic_match_buses[] = {
> +	&platform_bus_type,
> +#ifdef CONFIG_PCI
> +	&pci_bus_type,
> +#endif
> +#ifdef CONFIG_I2C
> +	&i2c_bus_type,
> +#endif
> +#ifdef CONFIG_SPI_MASTER
> +	&spi_bus_type,
> +#endif
> +	NULL,
> +};
> +
> +/* This tries to find the device from the most common bus types by name. */
> +static void *generic_match(struct devcon *con, int ep, void *data)
> +{
> +	struct bus_type *bus;
> +	struct device *dev;
> +
> +	for (bus = generic_match_buses[0]; bus; bus++) {
> +		dev = bus_find_device_by_name(bus, NULL, con->endpoint[ep]);
> +		if (dev)
> +			return dev;
> +	}
> +
> +	/*
> +	 * We only get called if a connection was found, tell the caller to

	                                          found; tell

> +	 * wait for the other device to show-up.

	                                show up.

> +	 */
> +	return ERR_PTR(-EPROBE_DEFER);
> +}
> +
> +/**
> + * device_find_connection - Find two devices connected together
> + * @dev: Device with the connection
> + * @con_id: Identifier for the connection
> + *
> + * Find a connection with unique identifier @con_id between @dev and an

                                                                    and

> + * other device. On success returns handle to the device that is connected

      another

> + * to @dev, with the reference count for the found device incremented. Returns
> + * NULL if no matching connection was found, or ERR_PTR(-EPROBE_DEFER) when a
> + * connection was found but the other device has not been enumerated yet.
> + */
> +struct device *device_find_connection(struct device *dev, const char *con_id)
> +{
> +	return __device_find_connection(dev, con_id, generic_match, NULL);
> +}
> +EXPORT_SYMBOL_GPL(device_find_connection);



-- 
~Randy

  reply	other threads:[~2018-02-25 19:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-25 15:24 [PATCH v2 00/12] USB Type-C device-connection, mux and switch support Hans de Goede
2018-02-25 15:24 ` [PATCH v2 01/12] drivers: base: Unified device connection lookup Hans de Goede
2018-02-25 19:04   ` Randy Dunlap [this message]
2018-02-25 15:25 ` [PATCH v2 02/12] usb: typec: Start using ERR_PTR Hans de Goede
2018-02-25 21:38   ` Guenter Roeck
2018-02-25 15:25 ` [PATCH v2 03/12] usb: typec: API for controlling USB Type-C Multiplexers Hans de Goede
2018-02-25 19:22   ` Randy Dunlap
2018-02-25 15:25 ` [PATCH v2 04/12] usb: common: Small class for USB role switches Hans de Goede
2018-02-25 15:25 ` [PATCH v2 05/12] usb: typec: tcpm: Set USB role switch to device mode when configured as such Hans de Goede
2018-02-25 21:33   ` Guenter Roeck
2018-02-25 15:25 ` [PATCH v2 06/12] usb: typec: tcpm: Use new Type-C switch/mux and usb-role-switch functions Hans de Goede
2018-02-25 21:38   ` Guenter Roeck
2018-02-25 15:25 ` [PATCH v2 07/12] xhci: Add option to get next extended capability in list by passing id = 0 Hans de Goede
2018-02-25 15:25 ` [PATCH v2 08/12] xhci: Add Intel extended cap / otg phy mux handling Hans de Goede
2018-02-25 15:25 ` [PATCH v2 09/12] usb: roles: Add Intel xHCI USB role switch driver Hans de Goede
2018-02-25 18:48   ` Randy Dunlap
2018-02-25 15:25 ` [PATCH v2 10/12] usb: typec: driver for Pericom PI3USB30532 Type-C cross switch Hans de Goede
2018-02-25 15:25 ` [PATCH v2 11/12] platform/x86: intel_cht_int33fe: Add device connections for the Type-C port Hans de Goede
2018-02-25 15:25 ` [PATCH v2 12/12] extcon: axp288: Set USB role where necessary Hans de Goede
2018-02-25 18:51   ` Randy Dunlap
2018-02-26  8:07     ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d89fe84-7196-fe60-86d9-29b05fa97ad8@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=andy@infradead.org \
    --cc=cw00.choi@samsung.com \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mathias.nyman@intel.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®