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
next prev parent 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®