linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
To: Jonathan Cameron <jic23@kernel.org>,
	Gwendal Grignou <gwendal@chromium.org>
Cc: briannorris@chromium.org, knaack.h@gmx.de, lars@metafoo.de,
	pmeerw@pmeerw.net, lee.jones@linaro.org, bleung@chromium.org,
	dianders@chromium.org, groeck@chromium.org,
	fabien.lahoudere@collabora.com, linux-kernel@vger.kernel.org,
	linux-iio@vger.kernel.org
Subject: Re: [PATCH v4 02/17] platform: cros_ec: Add cros_ec_sensor_hub driver
Date: Mon, 11 Nov 2019 10:24:01 +0100	[thread overview]
Message-ID: <dffd870b-fd0b-c7f4-218c-5b51bebea75c@collabora.com> (raw)
In-Reply-To: <20191110121004.0167542e@archlinux>

Hi,

On 10/11/19 13:10, Jonathan Cameron wrote:
> On Tue,  5 Nov 2019 14:26:37 -0800
> Gwendal Grignou <gwendal@chromium.org> wrote:
> 
>> Similar to HID sensor stack, the new driver sits between cros_ec_dev
>> and the iio device drivers:
>>
>> EC based iio device topology would be:
>> iio:device1 ->
>> ...0/0000:00:1f.0/PNP0C09:00/GOOG0004:00/cros-ec-dev.6.auto/
>>                                          cros-ec-sensorhub.7.auto/
>>                                          cros-ec-accel.15.auto/
>>                                          iio:device1
>>
>> It will be expanded to control EC sensor FIFO.
>>
>> Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
> 
> Random suggestion for a possible cleanup...
> 
> Would a devm_platform_device_register_data make sense?  Drops a
> fair bit of boilerplate in here.  If its not a common enough
> pattern, could use the devm_add_action_or_reset route
> to do the same thing.
> 

I don't think devm_platform_device_register exists, exist?

After solving the changes pointed by Jonathan the patch looks good to me.

> I would suggest this as a possible future element, but you
> have some other issues around that area that this would cleanup
> nicely for you.  See inline.
> 
> 
> Thanks,
> 
> Jonathan
> 
> 
> 
>> ---
>> Changes in v4:
>> - Use platform_device_register_data in children registration.
>> - Free registered pdev children at remove time.
>> - Remove useless includes
>> - Check patch with --strict option
>>     Use sizeof(*obj) instead of sizeof(struct ...obj)
>>     Alignement
>> - Describe cros_ec_sensorhub in kernel-doc format.
>> Changes in v3:
>> - Fix doxygen comments
>> - Fix use of ret |=
>> - Remove unncessary goto.
>> Changes in v2:
>> - Remove unerelated changes.
>> - Fix spelling.
>> - Use !x instead of x == NULL
>> - Use platform_ API directly to register IIO sensors from
>>   cros_ec_sensorhub.
>>
>>  drivers/iio/common/cros_ec_sensors/Kconfig    |   2 +-
>>  drivers/platform/chrome/Kconfig               |  12 +
>>  drivers/platform/chrome/Makefile              |   1 +
>>  drivers/platform/chrome/cros_ec_sensorhub.c   | 223 ++++++++++++++++++
>>  .../linux/platform_data/cros_ec_sensorhub.h   |  33 +++
>>  5 files changed, 270 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/platform/chrome/cros_ec_sensorhub.c
>>  create mode 100644 include/linux/platform_data/cros_ec_sensorhub.h
>>
>> diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig b/drivers/iio/common/cros_ec_sensors/Kconfig
>> index cdbb29cfb907..fefad9572790 100644
>> --- a/drivers/iio/common/cros_ec_sensors/Kconfig
>> +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
>> @@ -4,7 +4,7 @@
>>  #
>>  config IIO_CROS_EC_SENSORS_CORE
>>  	tristate "ChromeOS EC Sensors Core"
>> -	depends on SYSFS && CROS_EC
>> +	depends on SYSFS && CROS_EC_SENSORHUB
>>  	select IIO_BUFFER
>>  	select IIO_TRIGGERED_BUFFER
>>  	help
>> diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
>> index ee5f08ea57b6..56a25317a6be 100644
>> --- a/drivers/platform/chrome/Kconfig
>> +++ b/drivers/platform/chrome/Kconfig
>> @@ -190,6 +190,18 @@ config CROS_EC_DEBUGFS
>>  	  To compile this driver as a module, choose M here: the
>>  	  module will be called cros_ec_debugfs.
>>  
>> +config CROS_EC_SENSORHUB
>> +	tristate "ChromeOS EC MEMS Sensor Hub"
>> +	depends on CROS_EC && IIO
> 
> Could relax the IIO dependency I think...  Get you more build coverage.
> 
>> +	help
>> +	  Allow loading IIO sensors. This driver is loaded by MFD and will in
>> +	  turn query the EC and register the sensors.
>> +	  It also spreads the sensor data coming from the EC to the IIO sensor
>> +	  object.
>> +
>> +	  To compile this driver as a module, choose M here: the
>> +	  module will be called cros_ec_sensorhub.
>> +
>>  config CROS_EC_SYSFS
>>  	tristate "ChromeOS EC control and information through sysfs"
>>  	depends on MFD_CROS_EC_DEV && SYSFS
>> diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
>> index 477ec3d1d1c9..a164c40dc099 100644
>> --- a/drivers/platform/chrome/Makefile
>> +++ b/drivers/platform/chrome/Makefile
>> @@ -17,6 +17,7 @@ obj-$(CONFIG_CROS_EC_PROTO)		+= cros_ec_proto.o cros_ec_trace.o
>>  obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT)	+= cros_kbd_led_backlight.o
>>  obj-$(CONFIG_CROS_EC_CHARDEV)		+= cros_ec_chardev.o
>>  obj-$(CONFIG_CROS_EC_LIGHTBAR)		+= cros_ec_lightbar.o
>> +obj-$(CONFIG_CROS_EC_SENSORHUB)		+= cros_ec_sensorhub.o
>>  obj-$(CONFIG_CROS_EC_VBC)		+= cros_ec_vbc.o
>>  obj-$(CONFIG_CROS_EC_DEBUGFS)		+= cros_ec_debugfs.o
>>  obj-$(CONFIG_CROS_EC_SYSFS)		+= cros_ec_sysfs.o
>> diff --git a/drivers/platform/chrome/cros_ec_sensorhub.c b/drivers/platform/chrome/cros_ec_sensorhub.c
>> new file mode 100644
>> index 000000000000..6a0aa84cf092
>> --- /dev/null
>> +++ b/drivers/platform/chrome/cros_ec_sensorhub.c
>> @@ -0,0 +1,223 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * SensorHub: driver that discover sensors behind
>> + * a ChromeOS Embedded controller.
>> + *
>> + * Copyright 2019 Google LLC
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/device.h>
>> +#include <linux/module.h>
>> +#include <linux/mfd/cros_ec.h>
>> +#include <linux/platform_data/cros_ec_commands.h>
>> +#include <linux/platform_data/cros_ec_proto.h>
>> +#include <linux/platform_data/cros_ec_sensorhub.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +
>> +#define DRV_NAME		"cros-ec-sensorhub"
>> +
>> +static struct platform_device *cros_ec_sensorhub_allocate_single_sensor(
>> +		struct device *parent,
>> +		char *sensor_name,
>> +		int sensor_num)
>> +{
>> +	struct cros_ec_sensor_platform sensor_platforms = {
>> +		.sensor_num = sensor_num,
>> +	};
>> +
>> +	return platform_device_register_data(parent, sensor_name,
>> +				PLATFORM_DEVID_AUTO,
>> +				&sensor_platforms,
>> +				sizeof(sensor_platforms));
>> +}
>> +
>> +static int cros_ec_sensorhub_register(struct device *dev,
>> +				      struct cros_ec_sensorhub *sensorhub)
> 
> As noted below, I'd be happier if this function did it's own cleanup on
> error rather than leaving that for the caller.
> 
>> +{
>> +	int ret, i, id, sensor_num;
>> +	struct cros_ec_dev *ec = sensorhub->ec;
>> +	int sensor_type[MOTIONSENSE_TYPE_MAX] = { 0 };
>> +	struct ec_params_motion_sense *params;
>> +	struct ec_response_motion_sense *resp;
>> +	struct cros_ec_command *msg;
>> +	struct platform_device *pdev;
>> +	char *name;
>> +
>> +	sensor_num = cros_ec_get_sensor_count(ec);
>> +	if (sensor_num < 0) {
>> +		dev_err(dev,
>> +			"Unable to retrieve sensor information (err:%d)\n",
>> +			sensor_num);
>> +		return sensor_num;
>> +	}
>> +
>> +	if (sensor_num == 0) {
>> +		dev_err(dev, "Zero sensors reported.\n");
>> +		return -EINVAL;
>> +	}
>> +
>> +	/* Prepare a message to send INFO command to each sensor. */
>> +	msg = kzalloc(sizeof(*msg) + max(sizeof(*params), sizeof(*resp)),
>> +		      GFP_KERNEL);
>> +	if (!msg)
>> +		return -ENOMEM;
>> +
>> +	msg->version = 1;
>> +	msg->command = EC_CMD_MOTION_SENSE_CMD + ec->cmd_offset;
>> +	msg->outsize = sizeof(*params);
>> +	msg->insize = sizeof(*resp);
>> +	params = (struct ec_params_motion_sense *)msg->data;
>> +	resp = (struct ec_response_motion_sense *)msg->data;
>> +
>> +	id = 0;
>> +	for (i = 0; i < sensor_num; i++) {
>> +		params->cmd = MOTIONSENSE_CMD_INFO;
>> +		params->info.sensor_num = i;
>> +		ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
>> +		if (ret < 0) {
>> +			dev_warn(dev, "no info for EC sensor %d : %d/%d\n",
>> +				 i, ret, msg->result);
>> +			continue;
>> +		}
>> +		switch (resp->info.type) {
>> +		case MOTIONSENSE_TYPE_ACCEL:
>> +			name = "cros-ec-accel";
>> +			break;
>> +		case MOTIONSENSE_TYPE_BARO:
>> +			name = "cros-ec-baro";
>> +			break;
>> +		case MOTIONSENSE_TYPE_GYRO:
>> +			name = "cros-ec-gyro";
>> +			break;
>> +		case MOTIONSENSE_TYPE_MAG:
>> +			name = "cros-ec-mag";
>> +			break;
>> +		case MOTIONSENSE_TYPE_PROX:
>> +			name = "cros-ec-prox";
>> +			break;
>> +		case MOTIONSENSE_TYPE_LIGHT:
>> +			name = "cros-ec-light";
>> +			break;
>> +		case MOTIONSENSE_TYPE_ACTIVITY:
>> +			name = "cros-ec-activity";
>> +			break;
>> +		default:
>> +			dev_warn(dev, "unknown type %d\n", resp->info.type);
>> +			continue;
>> +		}
>> +		pdev = cros_ec_sensorhub_allocate_single_sensor(dev, name, i);
>> +		if (IS_ERR(pdev)) {
>> +			ret = IS_ERR(pdev);
>> +			goto error;
>> +		}
>> +		sensorhub->sensor_pdev[id++] = pdev;
>> +		sensor_type[resp->info.type]++;
>> +	}
>> +
>> +	if (sensor_type[MOTIONSENSE_TYPE_ACCEL] >= 2)
>> +		ec->has_kb_wake_angle = true;
>> +
>> +	if (cros_ec_check_features(ec,
>> +				   EC_FEATURE_REFINED_TABLET_MODE_HYSTERESIS)) {
>> +		pdev = cros_ec_sensorhub_allocate_single_sensor(dev,
>> +							"cros-ec-lid-angle", 0);
>> +		if (IS_ERR(pdev)) {
>> +			ret = IS_ERR(pdev);
>> +			goto error;
>> +		}
>> +		sensorhub->sensor_pdev[id++] = pdev;
>> +	}
>> +
>> +error:
>> +	kfree(msg);
>> +	return ret;
>> +}
>> +
>> +static int cros_ec_sensorhub_probe(struct platform_device *sensorhub_pdev)
>> +{
>> +	struct device *dev = &sensorhub_pdev->dev;
>> +	struct cros_ec_dev *ec = dev_get_drvdata(dev->parent);
>> +	int ret, i;
>> +	struct platform_device *pdev;
>> +	struct cros_ec_sensorhub *data =
>> +		kzalloc(sizeof(struct cros_ec_sensorhub), GFP_KERNEL);
> 
> Do we free this anywhere?  Could just use devm_kzalloc to do it
> automatically.
> 
>> +
>> +	if (!data)
>> +		return -ENOMEM;
>> +
>> +	data->ec = ec;
>> +	dev_set_drvdata(dev, data);
>> +
>> +	/* Check whether this EC is a sensor hub. */
>> +	if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE)) {
>> +		ret = cros_ec_sensorhub_register(dev, data);
>> +		if (ret) {
>> +			dev_err(dev, "Register failed %d\n", ret);
>> +			goto unregister_sensors;
> 
> From a code structure point of view, cros_ec_sensorhub_register
> should have done any cleanup necessary if it returns an error.  Hence
> we should be fine doing a direct return here (other than the memory
> not being freed comment above.
> 
> This may seem an overly restrictive request, but that sort of rule
> makes code a lot easier to review as we don't have to go look
> to see where the error handling occurs and check for multiple paths
> etc.  Note that if you use managed functions then there is no
> cleanup to do anyway ;)
> 
>> +		}
>> +	} else {
>> +		/*
>> +		 * If the device has sensors but does not claim to
>> +		 * be a sensor hub, we are in legacy mode.
>> +		 */
>> +		for (i = 0; i < 2; i++) {
>> +			pdev = cros_ec_sensorhub_allocate_single_sensor(dev,
>> +						"cros-ec-accel-legacy", i);
>> +			if (IS_ERR(pdev)) {
>> +				ret = IS_ERR(pdev);
>> +				dev_err(dev, "Legacy %d failed %d\n", i, ret);
>> +				goto unregister_sensors;
>> +			} else {
>> +				data->sensor_pdev[i] = pdev;
>> +			}
>> +		}
>> +	}
>> +
>> +	return 0;
>> +
>> +unregister_sensors:
>> +	/*
>> +	 * Given the probe has failed, we need to unregister all the sensors,
>> +	 * not jutst the one that did not work: this device will be
>> +	 * de-allocated.
>> +	 */
>> +	for (i = 0; i < CROS_EC_SENSOR_PDEV_MAX; i++) {
>> +		pdev = data->sensor_pdev[i];
>> +		if (pdev)
>> +			platform_device_unregister(pdev);
>> +	}
>> +	return ret;
>> +}
>> +
>> +static int cros_ec_sensorhub_remove(struct platform_device *sensorhub_pdev)
>> +{
>> +	struct cros_ec_sensorhub *sensorhub =
>> +		platform_get_drvdata(sensorhub_pdev);
>> +	struct platform_device *pdev;
>> +	int i;
>> +
>> +	for (i = 0; i < CROS_EC_SENSOR_PDEV_MAX; i++) {
>> +		pdev = sensorhub->sensor_pdev[i];
>> +		if (pdev)
>> +			platform_device_unregister(pdev);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static struct platform_driver cros_ec_sensorhub_driver = {
>> +	.driver = {
>> +		.name = DRV_NAME,
>> +	},
>> +	.probe = cros_ec_sensorhub_probe,
>> +	.remove = cros_ec_sensorhub_remove,
>> +};
>> +
>> +module_platform_driver(cros_ec_sensorhub_driver);
>> +
>> +MODULE_ALIAS("platform:" DRV_NAME);
>> +MODULE_AUTHOR("Gwendal Grignou <gwendal@chromium.org>");
>> +MODULE_DESCRIPTION("ChromeOS EC MEMS Sensor Hub Driver");
>> +MODULE_LICENSE("GPL");
>> diff --git a/include/linux/platform_data/cros_ec_sensorhub.h b/include/linux/platform_data/cros_ec_sensorhub.h
>> new file mode 100644
>> index 000000000000..da0ba1d201e4
>> --- /dev/null
>> +++ b/include/linux/platform_data/cros_ec_sensorhub.h
>> @@ -0,0 +1,33 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * cros_ec_sensorhub- Chrome OS EC MEMS Sensor Hub driver.
>> + *
>> + * Copyright (C) 2019 Google, Inc
>> + */
>> +
>> +#ifndef __LINUX_PLATFORM_DATA_CROS_EC_SENSORHUB_H
>> +#define __LINUX_PLATFORM_DATA_CROS_EC_SENSORHUB_H
>> +
>> +#include <linux/platform_data/cros_ec_commands.h>
>> +
>> +/* Maximal number of sensors supported by the EC. */
>> +#define CROS_EC_SENSOR_MAX 16
>> +
>> +/*
>> + * Maximal number of sensors supported by the hub:
>> + * We add one for the lid angle inclinometer sensor.
>> + */
>> +#define CROS_EC_SENSOR_PDEV_MAX (CROS_EC_SENSOR_MAX + 1)
>> +
>> +/**
>> + * struct cros_ec_sensorhub - Sensor Hub device data.
>> + *
>> + * @ec:           Embedded Controller where the hub is located.
>> + * @sensor_pdev:  Array of platform_device, one per sensor.
>> + */
>> +struct cros_ec_sensorhub {
>> +	struct cros_ec_dev *ec;
>> +	struct platform_device *sensor_pdev[CROS_EC_SENSOR_PDEV_MAX];
>> +};
>> +
>> +#endif   /* __LINUX_PLATFORM_DATA_CROS_EC_SENSORHUB_H */
> 

  reply	other threads:[~2019-11-11  9:24 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 22:26 [PATCH v4 00/17] cros_ec: Add sensorhub driver and FIFO processing Gwendal Grignou
2019-11-05 22:26 ` [PATCH v4 01/17] mfd: cros_ec: Add sensor_count and make check_features public Gwendal Grignou
2019-11-08 22:03   ` Enric Balletbo Serra
2019-11-11 11:44     ` Lee Jones
2019-11-16 11:49       ` Jonathan Cameron
2019-11-05 22:26 ` [PATCH v4 02/17] platform: cros_ec: Add cros_ec_sensor_hub driver Gwendal Grignou
2019-11-10 12:10   ` Jonathan Cameron
2019-11-11  9:24     ` Enric Balletbo i Serra [this message]
2019-11-11 11:55       ` Jonathan Cameron
2019-11-05 22:26 ` [PATCH v4 03/17] platform/mfd:iio: cros_ec: Register sensor through sensorhub Gwendal Grignou
2019-11-10 12:13   ` Jonathan Cameron
2019-11-11  9:25     ` Enric Balletbo i Serra
2019-11-11 11:43   ` Lee Jones
2019-11-05 22:26 ` [PATCH v4 04/17] platform: chrome: cros-ec: record event timestamp in the hard irq Gwendal Grignou
2019-11-10 12:16   ` Jonathan Cameron
2019-11-11  9:27     ` Enric Balletbo i Serra
2019-11-05 22:26 ` [PATCH v4 05/17] platform: chrome: cros_ec: Do not attempt to register a non-positive IRQ number Gwendal Grignou
2019-11-10 12:17   ` Jonathan Cameron
2019-11-11  9:29     ` Enric Balletbo i Serra
2019-11-14  0:58       ` Gwendal Grignou
2019-11-05 22:26 ` [PATCH v4 06/17] platform: chrome: cros_ec: handle MKBP more events flag Gwendal Grignou
2019-11-10 12:28   ` Jonathan Cameron
2019-11-11  9:30     ` Enric Balletbo i Serra
2019-11-05 22:26 ` [PATCH v4 07/17] Revert "Input: cros_ec_keyb - add back missing mask for event_type" Gwendal Grignou
2019-11-11  9:20   ` Enric Balletbo i Serra
2019-11-11 19:23     ` Dmitry Torokhov
2019-11-05 22:26 ` [PATCH v4 08/17] Revert "Input: cros_ec_keyb: mask out extra flags in event_type" Gwendal Grignou
2019-11-11  9:20   ` Enric Balletbo i Serra
2019-11-11 19:23     ` Dmitry Torokhov
2019-11-05 22:26 ` [PATCH v4 09/17] platform: chrome: sensorhub: Add FIFO support Gwendal Grignou
2019-11-06 21:13   ` Gwendal Grignou
2019-11-10 12:54     ` Jonathan Cameron
2019-11-14  1:01       ` Gwendal Grignou
2019-11-05 22:26 ` [PATCH v4 10/17] platform: chrome: sensorhub: Add code to spread timestmap Gwendal Grignou
2019-11-10 12:57   ` Jonathan Cameron
2019-11-05 22:26 ` [PATCH v4 11/17] platform: chrome: sensorhub: Add median filter Gwendal Grignou
2019-11-10 13:07   ` Jonathan Cameron
2019-11-05 22:26 ` [PATCH v4 12/17] iio: cros_ec: Move function description to .c file Gwendal Grignou
2019-11-10 13:08   ` Jonathan Cameron
2019-11-11  9:35     ` Enric Balletbo i Serra
2019-11-05 22:26 ` [PATCH v4 13/17] iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO Gwendal Grignou
2019-11-10 13:17   ` Jonathan Cameron
2019-11-14 18:17     ` Gwendal Grignou
2019-11-05 22:26 ` [PATCH v4 14/17] iio: cros_ec: Remove pm function Gwendal Grignou
2019-11-10 13:18   ` Jonathan Cameron
2019-11-11  9:37     ` Enric Balletbo i Serra
2019-11-05 22:26 ` [PATCH v4 15/17] iio: cros_ec: Expose hwfifo_timeout Gwendal Grignou
2019-11-10 13:21   ` Jonathan Cameron
2019-11-05 22:26 ` [PATCH v4 16/17] iio: cros_ec: Report hwfifo_watermark_max Gwendal Grignou
2019-11-10 13:22   ` Jonathan Cameron
2019-11-05 22:26 ` [PATCH v4 17/17] iio: cros_ec: Use Hertz as unit for sampling frequency Gwendal Grignou
2019-11-10 13:24   ` Jonathan Cameron

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=dffd870b-fd0b-c7f4-218c-5b51bebea75c@collabora.com \
    --to=enric.balletbo@collabora.com \
    --cc=bleung@chromium.org \
    --cc=briannorris@chromium.org \
    --cc=dianders@chromium.org \
    --cc=fabien.lahoudere@collabora.com \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=lee.jones@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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;
as well as URLs for NNTP newsgroup(s).