Date:   Wed, 14 Mar 2018 14:13:23 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Guenter Roeck <linux@...ck-us.net>, Jun Li <jun.li@....com>,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org
Subject: Re: [PATCH v7 01/12] drivers: base: Unified device connection lookup

On Wed, Mar 14, 2018 at 12:16:05PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 12, 2018 at 05:34:20PM +0300, Heikki Krogerus wrote:
> > 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.
> > 
> > Reviewed-by: Hans de Goede <hdegoede@...hat.com>
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@...il.com>
> > Signed-off-by: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
> > ---
> > Changes in v7:
> > - API naming improvements suggested by Greg
> > - Prototypes to device.h, also suggested by Greg
> > - I removed the DEVCON() macro as it was not used yet and it needs to be
> >   rewritten
> > 
> > Changes in v6:
> > -Fix data and match arguments being swapped in __device_find_connection()
> >  call in device_find_connection() (as noticed by Jun Li)
> > 
> > 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                          | 141 +++++++++++++++++++++++++
> >  include/linux/device.h                         |  22 ++++
> >  4 files changed, 208 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/driver-api/device_connection.rst
> >  create mode 100644 drivers/base/devcon.c
> > 
> > diff --git a/Documentation/driver-api/device_connection.rst b/Documentation/driver-api/device_connection.rst
> > new file mode 100644
> > index 000000000000..affbc5566ab0
> > --- /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_connection_find_match device_connection_find device_connection_add device_connection_remove
> > 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 000000000000..e783c2c2ed1a
> > --- /dev/null
> > +++ b/drivers/base/devcon.c
> > @@ -0,0 +1,141 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/**
> > + * Device connections
> > + *
> > + * Copyright (C) 2018 Intel Corporation
> > + * Author: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
> > + */
> > +
> > +#include <linux/device.h>
> > +
> > +static DEFINE_MUTEX(devcon_lock);
> > +static LIST_HEAD(devcon_list);
> > +
> > +/**
> > + * device_connection_find_match - 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 data the
> > + * caller is expecting to be returned.
> > + */
> > +void *device_connection_find_match(struct device *dev, const char *con_id,
> > +			       void *data,
> > +			       void *(*match)(struct device_connection *con,
> > +					      int ep, void *data))
> > +{
> > +	const char *devname = dev_name(dev);
> > +	struct device_connection *con;
> > +	void *ret = NULL;
> > +	int ep;
> > +
> > +	if (!match)
> > +		return NULL;
> > +
> > +	rcu_read_lock();
> 
> Wait, why are you using rcu at all for this?  This is not a "heavy"
> operation that you need to care about speed for, right?  Why get rcu
> involved at all in this type of thing?
> 
> Yes, the links in the driver core seem to be using rcu, which I didn't
> notice until right now, and I can't remember why or when that happened.
> Let's not make this more complex than it has to be please.

OK. Makes sense.

> Sorry I missed this the last review cycles.

Np. I'll prepare v8. This will not affect the other patches, so is it
enough if I just update this patch? Or do you prefer that I re-send
the whole series?


Thanks,

-- 
heikki

Powered by blists - more mailing lists