All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Vinod Koul <vkoul@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans de Goede <hdegoede@redhat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Daniel Scally <djrscally@gmail.com>,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org
Subject: Re: [PATCH 3/8] device property: Helper to match multiple connections
Date: Wed, 5 Jan 2022 12:43:28 -0800	[thread overview]
Message-ID: <YdYC8DeF1i9a3RnP@ripper> (raw)
In-Reply-To: <Yc7I3gZehc1lHn4Z@paasikivi.fi.intel.com>

On Fri 31 Dec 01:09 PST 2021, Sakari Ailus wrote:

> Hi Björn,
> 
> (And thanks to Heikki for cc'ing me!)
> 
> On Thu, Dec 30, 2021 at 11:26:34AM +0200, Heikki Krogerus wrote:
> > +Andy, Dan and Sakari
> > 
> > On Mon, Dec 27, 2021 at 09:21:11PM -0800, Bjorn Andersson wrote:
> > > In some cases multiple connections with the same connection id
> > > needs to be resolved from a fwnode graph.
> > > 
> > > One such example is when separate hardware is used for performing muxing and/or
> > > orientation switching of the SuperSpeed and SBU lines in a USB-C
> > > connector. In this case the connector needs to belong to a graph with
> > > multiple matching remote endpoints, and the TypeC controller needs to be
> > > able to resolve them both.
> > > 
> > > Add a new API that allows this kind of lookup.
> > > 
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> > >  drivers/base/property.c  | 94 ++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/property.h |  5 +++
> > >  2 files changed, 99 insertions(+)
> > > 
> > > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > > index cbe4fa298413..0aa0296fd991 100644
> > > --- a/drivers/base/property.c
> > > +++ b/drivers/base/property.c
> > > @@ -1180,6 +1180,36 @@ fwnode_graph_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > >  	return NULL;
> > >  }
> > >  
> > > +static unsigned int fwnode_graph_devcon_matches(struct fwnode_handle *fwnode,
> > > +						const char *con_id, void *data,
> > > +						devcon_match_fn_t match,
> > > +						void **matches,
> > > +						unsigned int matches_len)
> > > +{
> > > +	struct fwnode_handle *node;
> > > +	struct fwnode_handle *ep;
> > > +	unsigned int count = 0;
> > > +	void *ret;
> > > +
> > > +	fwnode_graph_for_each_endpoint(fwnode, ep) {
> > > +		if (count >= matches_len) {
> > > +			fwnode_handle_put(ep);
> > > +			return count;
> > > +		}
> > > +
> > > +		node = fwnode_graph_get_remote_port_parent(ep);
> > > +		if (!fwnode_device_is_available(node))
> 
> The reference to node needs to be put here.
> 

You're right, thanks!

> > > +			continue;
> > > +
> > > +		ret = match(node, con_id, data);
> > > +		fwnode_handle_put(node);
> > > +
> > > +		if (ret)
> > > +			matches[count++] = ret;
> > > +	}
> > > +	return count;
> > > +}
> > > +
> > >  static void *
> > >  fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > >  		    void *data, devcon_match_fn_t match)
> > > @@ -1202,6 +1232,35 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > >  	return NULL;
> > >  }
> > >  
> > > +static unsigned int fwnode_devcon_matches(struct fwnode_handle *fwnode,
> > > +					  const char *con_id, void *data,
> > > +					  devcon_match_fn_t match,
> > > +					  void **matches,
> > > +					  unsigned int matches_len)
> > > +{
> > > +	struct fwnode_handle *node;
> > > +	unsigned int count = 0;
> > > +	void *ret;
> > > +	int i;
> 
> unsigned int, please.
> 

Sounds good.

> > > +
> > > +	for (i = 0; ; i++) {
> > > +		if (count >= matches_len)
> > > +			return count;
> > > +
> > > +		node = fwnode_find_reference(fwnode, con_id, i);
> > > +		if (IS_ERR(node))
> > > +			break;
> > > +
> > > +		ret = match(node, NULL, data);
> > > +		fwnode_handle_put(node);
> > > +
> > > +		if (ret)
> > > +			matches[count++] = ret;
> > > +	}
> > > +
> > > +	return count;
> > > +}
> > > +
> > >  /**
> > >   * fwnode_connection_find_match - Find connection from a device node
> > >   * @fwnode: Device node with the connection
> > > @@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode,
> > >  	return fwnode_devcon_match(fwnode, con_id, data, match);
> > >  }
> > >  EXPORT_SYMBOL_GPL(fwnode_connection_find_match);
> > > +
> > > +/**
> > > + * fwnode_connection_find_matches - Find connections from a device node
> > > + * @fwnode: Device node with the connection
> > > + * @con_id: Identifier for the connection
> > > + * @data: Data for the match function
> > > + * @match: Function to check and convert the connection description
> > > + * @matches: Array of pointers to fill with matches
> > > + * @matches_len: Length of @matches
> > > + *
> > > + * Find up to @matches_len connections with unique identifier @con_id between
> > > + * @fwnode and other device nodes. @match will be used to convert the
> > > + * connection description to data the caller is expecting to be returned
> > > + * through the @matches array.
> 
> If the caller allocates the matches array, how does it know how large it
> should be? Is there a need to provide a way to count the matches before
> writing them to an array? Most similar functions do that by just setting the
> array (matches) to NULL.
> 

This is a very relevant comment and I did look for ways to handle this
as I came up with the patch.

I think the typical mechanism would be to allow @matches to be NULL, in
which case we iterate over objects and return the number of matches, so
that the caller can allocate an appropriately sized array and call the
API again.

But the "match" function simply returns a pointer to something and
looking at the example of the typec_{mux,switch} this pointer points to
a member of an object which has a struct device which is refcounted.

As such, we can't simply discard the returned object. We have to pass it
back to the caller, whom knows what "match" did and is able to reverse
that.

I looked at changing the callback and I looked at using krealloc() to
grow an array dynamically.


But looking at the use case in mind; finding entities that might need to
react to a USB Type-C event I have a need for 2 matches, and 3 seems
plausible. Beyond that the largest of_graph I have ever dealt with has 6
endpoints.

While it isn't relevant to use this API for my 6-endpoint case, it would
result in @matches having to be 48 bytes of pointers. And once the call
returns, the actual number of pointers needed is known and the long-term
storage can be re-allocated as necessary based on the return value.

As such, I dropped the idea of making something fancier and more
dynamic, for the sake of simplicity. Perhaps I'm missing some cool use
case where this is infeasible?

Regards,
Bjorn

> > > + *
> > > + * Return: Number of matches resolved, of negative errno.
> > > + */
> > > +int fwnode_connection_find_matches(struct fwnode_handle *fwnode,
> > > +				   const char *con_id, void *data,
> > > +				   devcon_match_fn_t match,
> > > +				   void **matches, unsigned int matches_len)
> > > +{
> > > +	unsigned int count;
> > > +
> > > +	if (!fwnode || !match || !matches)
> > > +		return -EINVAL;
> > > +
> > > +	count = fwnode_graph_devcon_matches(fwnode, con_id, data, match,
> > > +					    matches, matches_len);
> > > +
> > > +	return count + fwnode_devcon_matches(fwnode, con_id, data, match,
> > > +					     matches + count,
> > > +					     matches_len - count);
> > > +}
> > > +EXPORT_SYMBOL_GPL(fwnode_connection_find_matches);
> > > diff --git a/include/linux/property.h b/include/linux/property.h
> > > index 16f736c698a2..59484ccb260e 100644
> > > --- a/include/linux/property.h
> > > +++ b/include/linux/property.h
> > > @@ -444,6 +444,11 @@ static inline void *device_connection_find_match(struct device *dev,
> > >  	return fwnode_connection_find_match(dev_fwnode(dev), con_id, data, match);
> > >  }
> > >  
> > > +int fwnode_connection_find_matches(struct fwnode_handle *fwnode,
> > > +				   const char *con_id, void *data,
> > > +				   devcon_match_fn_t match,
> > > +				   void **matches, unsigned int matches_len);
> > > +
> > >  /* -------------------------------------------------------------------------- */
> > >  /* Software fwnode support - when HW description is incomplete or missing */
> > >  
> 
> -- 
> Kind regards,
> 
> Sakari Ailus

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Vinod Koul <vkoul@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans de Goede <hdegoede@redhat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Daniel Scally <djrscally@gmail.com>,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org
Subject: Re: [PATCH 3/8] device property: Helper to match multiple connections
Date: Wed, 5 Jan 2022 12:43:28 -0800	[thread overview]
Message-ID: <YdYC8DeF1i9a3RnP@ripper> (raw)
In-Reply-To: <Yc7I3gZehc1lHn4Z@paasikivi.fi.intel.com>

On Fri 31 Dec 01:09 PST 2021, Sakari Ailus wrote:

> Hi Björn,
> 
> (And thanks to Heikki for cc'ing me!)
> 
> On Thu, Dec 30, 2021 at 11:26:34AM +0200, Heikki Krogerus wrote:
> > +Andy, Dan and Sakari
> > 
> > On Mon, Dec 27, 2021 at 09:21:11PM -0800, Bjorn Andersson wrote:
> > > In some cases multiple connections with the same connection id
> > > needs to be resolved from a fwnode graph.
> > > 
> > > One such example is when separate hardware is used for performing muxing and/or
> > > orientation switching of the SuperSpeed and SBU lines in a USB-C
> > > connector. In this case the connector needs to belong to a graph with
> > > multiple matching remote endpoints, and the TypeC controller needs to be
> > > able to resolve them both.
> > > 
> > > Add a new API that allows this kind of lookup.
> > > 
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> > >  drivers/base/property.c  | 94 ++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/property.h |  5 +++
> > >  2 files changed, 99 insertions(+)
> > > 
> > > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > > index cbe4fa298413..0aa0296fd991 100644
> > > --- a/drivers/base/property.c
> > > +++ b/drivers/base/property.c
> > > @@ -1180,6 +1180,36 @@ fwnode_graph_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > >  	return NULL;
> > >  }
> > >  
> > > +static unsigned int fwnode_graph_devcon_matches(struct fwnode_handle *fwnode,
> > > +						const char *con_id, void *data,
> > > +						devcon_match_fn_t match,
> > > +						void **matches,
> > > +						unsigned int matches_len)
> > > +{
> > > +	struct fwnode_handle *node;
> > > +	struct fwnode_handle *ep;
> > > +	unsigned int count = 0;
> > > +	void *ret;
> > > +
> > > +	fwnode_graph_for_each_endpoint(fwnode, ep) {
> > > +		if (count >= matches_len) {
> > > +			fwnode_handle_put(ep);
> > > +			return count;
> > > +		}
> > > +
> > > +		node = fwnode_graph_get_remote_port_parent(ep);
> > > +		if (!fwnode_device_is_available(node))
> 
> The reference to node needs to be put here.
> 

You're right, thanks!

> > > +			continue;
> > > +
> > > +		ret = match(node, con_id, data);
> > > +		fwnode_handle_put(node);
> > > +
> > > +		if (ret)
> > > +			matches[count++] = ret;
> > > +	}
> > > +	return count;
> > > +}
> > > +
> > >  static void *
> > >  fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > >  		    void *data, devcon_match_fn_t match)
> > > @@ -1202,6 +1232,35 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > >  	return NULL;
> > >  }
> > >  
> > > +static unsigned int fwnode_devcon_matches(struct fwnode_handle *fwnode,
> > > +					  const char *con_id, void *data,
> > > +					  devcon_match_fn_t match,
> > > +					  void **matches,
> > > +					  unsigned int matches_len)
> > > +{
> > > +	struct fwnode_handle *node;
> > > +	unsigned int count = 0;
> > > +	void *ret;
> > > +	int i;
> 
> unsigned int, please.
> 

Sounds good.

> > > +
> > > +	for (i = 0; ; i++) {
> > > +		if (count >= matches_len)
> > > +			return count;
> > > +
> > > +		node = fwnode_find_reference(fwnode, con_id, i);
> > > +		if (IS_ERR(node))
> > > +			break;
> > > +
> > > +		ret = match(node, NULL, data);
> > > +		fwnode_handle_put(node);
> > > +
> > > +		if (ret)
> > > +			matches[count++] = ret;
> > > +	}
> > > +
> > > +	return count;
> > > +}
> > > +
> > >  /**
> > >   * fwnode_connection_find_match - Find connection from a device node
> > >   * @fwnode: Device node with the connection
> > > @@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode,
> > >  	return fwnode_devcon_match(fwnode, con_id, data, match);
> > >  }
> > >  EXPORT_SYMBOL_GPL(fwnode_connection_find_match);
> > > +
> > > +/**
> > > + * fwnode_connection_find_matches - Find connections from a device node
> > > + * @fwnode: Device node with the connection
> > > + * @con_id: Identifier for the connection
> > > + * @data: Data for the match function
> > > + * @match: Function to check and convert the connection description
> > > + * @matches: Array of pointers to fill with matches
> > > + * @matches_len: Length of @matches
> > > + *
> > > + * Find up to @matches_len connections with unique identifier @con_id between
> > > + * @fwnode and other device nodes. @match will be used to convert the
> > > + * connection description to data the caller is expecting to be returned
> > > + * through the @matches array.
> 
> If the caller allocates the matches array, how does it know how large it
> should be? Is there a need to provide a way to count the matches before
> writing them to an array? Most similar functions do that by just setting the
> array (matches) to NULL.
> 

This is a very relevant comment and I did look for ways to handle this
as I came up with the patch.

I think the typical mechanism would be to allow @matches to be NULL, in
which case we iterate over objects and return the number of matches, so
that the caller can allocate an appropriately sized array and call the
API again.

But the "match" function simply returns a pointer to something and
looking at the example of the typec_{mux,switch} this pointer points to
a member of an object which has a struct device which is refcounted.

As such, we can't simply discard the returned object. We have to pass it
back to the caller, whom knows what "match" did and is able to reverse
that.

I looked at changing the callback and I looked at using krealloc() to
grow an array dynamically.


But looking at the use case in mind; finding entities that might need to
react to a USB Type-C event I have a need for 2 matches, and 3 seems
plausible. Beyond that the largest of_graph I have ever dealt with has 6
endpoints.

While it isn't relevant to use this API for my 6-endpoint case, it would
result in @matches having to be 48 bytes of pointers. And once the call
returns, the actual number of pointers needed is known and the long-term
storage can be re-allocated as necessary based on the return value.

As such, I dropped the idea of making something fancier and more
dynamic, for the sake of simplicity. Perhaps I'm missing some cool use
case where this is infeasible?

Regards,
Bjorn

> > > + *
> > > + * Return: Number of matches resolved, of negative errno.
> > > + */
> > > +int fwnode_connection_find_matches(struct fwnode_handle *fwnode,
> > > +				   const char *con_id, void *data,
> > > +				   devcon_match_fn_t match,
> > > +				   void **matches, unsigned int matches_len)
> > > +{
> > > +	unsigned int count;
> > > +
> > > +	if (!fwnode || !match || !matches)
> > > +		return -EINVAL;
> > > +
> > > +	count = fwnode_graph_devcon_matches(fwnode, con_id, data, match,
> > > +					    matches, matches_len);
> > > +
> > > +	return count + fwnode_devcon_matches(fwnode, con_id, data, match,
> > > +					     matches + count,
> > > +					     matches_len - count);
> > > +}
> > > +EXPORT_SYMBOL_GPL(fwnode_connection_find_matches);
> > > diff --git a/include/linux/property.h b/include/linux/property.h
> > > index 16f736c698a2..59484ccb260e 100644
> > > --- a/include/linux/property.h
> > > +++ b/include/linux/property.h
> > > @@ -444,6 +444,11 @@ static inline void *device_connection_find_match(struct device *dev,
> > >  	return fwnode_connection_find_match(dev_fwnode(dev), con_id, data, match);
> > >  }
> > >  
> > > +int fwnode_connection_find_matches(struct fwnode_handle *fwnode,
> > > +				   const char *con_id, void *data,
> > > +				   devcon_match_fn_t match,
> > > +				   void **matches, unsigned int matches_len);
> > > +
> > >  /* -------------------------------------------------------------------------- */
> > >  /* Software fwnode support - when HW description is incomplete or missing */
> > >  
> 
> -- 
> Kind regards,
> 
> Sakari Ailus

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2022-01-05 20:42 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-28  5:21 [PATCH 0/8] typec: mux: Introduce support for multiple TypeC muxes Bjorn Andersson
2021-12-28  5:21 ` Bjorn Andersson
2021-12-28  5:21 ` [PATCH 1/8] dt-bindings: phy: qcom,qmp-usb3-dp: Add altmode/switch properties Bjorn Andersson
2021-12-28  5:21   ` [PATCH 1/8] dt-bindings: phy: qcom, qmp-usb3-dp: " Bjorn Andersson
2021-12-28  5:21 ` [PATCH 2/8] phy: qcom-qmp: Register typec mux and orientation switch Bjorn Andersson
2021-12-28  5:21   ` Bjorn Andersson
2021-12-28 12:25   ` Dmitry Baryshkov
2021-12-28 12:25     ` Dmitry Baryshkov
2021-12-28 13:59   ` kernel test robot
2021-12-28 13:59     ` kernel test robot
2021-12-28 13:59     ` kernel test robot
2021-12-28 16:20     ` Bjorn Andersson
2021-12-28 16:20       ` Bjorn Andersson
2021-12-28 16:20       ` Bjorn Andersson
2021-12-29  5:27   ` Vinod Koul
2021-12-29  5:27     ` Vinod Koul
2022-01-07 19:15     ` Bjorn Andersson
2022-01-07 19:15       ` Bjorn Andersson
2021-12-28  5:21 ` [PATCH 3/8] device property: Helper to match multiple connections Bjorn Andersson
2021-12-28  5:21   ` Bjorn Andersson
2021-12-28 13:09   ` Dmitry Baryshkov
2021-12-28 13:09     ` Dmitry Baryshkov
2021-12-28 17:04     ` Bjorn Andersson
2021-12-28 17:04       ` Bjorn Andersson
2021-12-28 18:24       ` Dmitry Baryshkov
2021-12-28 18:24         ` Dmitry Baryshkov
2021-12-28 18:42         ` Bjorn Andersson
2021-12-28 18:42           ` Bjorn Andersson
2021-12-29  5:40       ` Vinod Koul
2021-12-29  5:40         ` Vinod Koul
2021-12-30  9:26   ` Heikki Krogerus
2021-12-30  9:26     ` Heikki Krogerus
2021-12-31  9:09     ` Sakari Ailus
2021-12-31  9:09       ` Sakari Ailus
2022-01-05 20:43       ` Bjorn Andersson [this message]
2022-01-05 20:43         ` Bjorn Andersson
2022-01-07 14:33         ` Sakari Ailus
2022-01-07 14:33           ` Sakari Ailus
2022-01-07 15:15           ` Bjorn Andersson
2022-01-07 15:15             ` Bjorn Andersson
2021-12-28  5:21 ` [PATCH 4/8] device property: Use multi-connection matchers for single case Bjorn Andersson
2021-12-28  5:21   ` Bjorn Andersson
2021-12-28  5:21 ` [PATCH 5/8] typec: mux: Introduce indirection Bjorn Andersson
2021-12-28  5:21   ` Bjorn Andersson
2021-12-28  5:21 ` [PATCH 6/8] typec: mux: Allow multiple mux_devs per mux Bjorn Andersson
2021-12-28  5:21   ` Bjorn Andersson
2021-12-28 16:04   ` Dmitry Baryshkov
2021-12-28 16:04     ` Dmitry Baryshkov
2021-12-28 16:40     ` Bjorn Andersson
2021-12-28 16:40       ` Bjorn Andersson
2021-12-28  5:21 ` [PATCH 7/8] dt-bindings: usb: Add binding for fcs,fsa4480 Bjorn Andersson
2021-12-28  5:21   ` Bjorn Andersson
2021-12-28  5:21 ` [PATCH 8/8] usb: typec: mux: Add On Semi fsa4480 driver Bjorn Andersson
2021-12-28  5:21   ` Bjorn Andersson
2021-12-28 12:20 ` [PATCH 0/8] typec: mux: Introduce support for multiple TypeC muxes Hans de Goede
2021-12-28 12:20   ` Hans de Goede
2021-12-28 17:08   ` Bjorn Andersson
2021-12-28 17:08     ` Bjorn Andersson
2021-12-28 15:41 [PATCH 6/8] typec: mux: Allow multiple mux_devs per mux kernel test robot
2022-01-06 10:43 ` Dan Carpenter
2022-01-06 10:43 ` Dan Carpenter
2022-01-06 10:43 ` Dan Carpenter

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=YdYC8DeF1i9a3RnP@ripper \
    --to=bjorn.andersson@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=djrscally@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=kishon@ti.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=vkoul@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.