From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Agustin Vega-Frias <agustinv@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Marc Zyngier <marc.zyngier@arm.com>,
Timur Tabi <timur@codeaurora.org>,
Christopher Covington <cov@codeaurora.org>,
Andy Gross <agross@codeaurora.org>,
harba@codeaurora.org, Jon Masters <jcm@redhat.com>,
msalter@redhat.com, mlangsdo@redhat.com,
Al Stone <ahs3@redhat.com>,
astone@redhat.com, Graeme Gregory <graeme.gregory@linaro.org>,
guohanjun@huawei.com, Charles Garcia-Tobin <charles.garc>
Subject: Re: [PATCH V11 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
Date: Thu, 26 Jan 2017 10:15:21 +0000 [thread overview]
Message-ID: <20170126101521.GA10324@red-moon> (raw)
In-Reply-To: <CAHp75VeYxfuMuaZCMk+MYdxLTs7cCa6j6M7Ot3XnwMmeHP7kBA@mail.gmail.com>
On Thu, Jan 26, 2017 at 03:01:18AM +0200, Andy Shevchenko wrote:
> On Fri, Jan 20, 2017 at 4:34 AM, Agustin Vega-Frias
> <agustinv@codeaurora.org> wrote:
> > ACPI extended IRQ resources may contain a ResourceSource to specify
> > an alternate interrupt controller. Introduce acpi_irq_get and use it
> > to implement ResourceSource/IRQ domain mapping.
> >
> > The new API is similar to of_irq_get and allows re-initialization
> > of a platform resource from the ACPI extended IRQ resource, and
> > provides proper behavior for probe deferral when the domain is not
> > yet present when called.
>
> > +static struct fwnode_handle *
> > +acpi_get_irq_source_fwhandle(const struct acpi_resource_source *source)
> > +{
> > + struct fwnode_handle *result = NULL;
> > + struct acpi_device *device;
> > + struct acpi_hardware_id *hwid;
> > + struct acpi_device_id *devid;
> > + acpi_handle handle;
> > + acpi_status status;
> > +
> > + if (!source->string_length)
> > + return acpi_gsi_domain_id;
> > +
> > + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> > + if (WARN_ON(ACPI_FAILURE(status)))
> > + return NULL;
> > +
> > + device = acpi_bus_get_acpi_device(handle);
> > + if (WARN_ON(!device))
> > + return NULL;
> > +
>
> > + list_for_each_entry(hwid, &device->pnp.ids, list) {
>
> > + for (devid = &__dsdt_irqchip_acpi_probe_table;
> > + devid < &__dsdt_irqchip_acpi_probe_table_end; devid++) {
> > + if (devid->id && !strcmp(devid->id, hwid->id)) {
> > + result = &device->fwnode;
> > + break;
> > + }
> > + }
>
> Looks like a candidate for linker table API. (I recommend to Cc Luis
> for this part)
This linker table entry scheme is just an optimization and should
not gate the series.
> > + }
>
> > +/**
> > + * acpi_irq_parse_one_match - Handle a matching IRQ resource.
> > + * @fwnode: matching fwnode
> > + * @hwirq: hardware IRQ number
> > + * @triggering: triggering attributes of hwirq
> > + * @polarity: polarity attributes of hwirq
> > + * @polarity: polarity attributes of hwirq
> > + * @shareable: shareable attributes of hwirq
> > + * @ctx: acpi_irq_parse_one_ctx updated by this function
> > + *
> > + * Description:
> > + * Handle a matching IRQ resource by populating the given ctx with
> > + * the information passed.
> > + */
> > +static inline void acpi_irq_parse_one_match(struct fwnode_handle *fwnode,
> > + u32 hwirq, u8 triggering,
> > + u8 polarity, u8 shareable,
> > + struct acpi_irq_parse_one_ctx *ctx)
> > +{
>
> > + if (!fwnode)
> > + return;
>
> > + ctx->rc = 0;
>
> Perhaps ctx->rc = fwnode ? 0 : -EINVAL; ?
>
> > + *ctx->res_flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> > + ctx->fwspec->fwnode = fwnode;
> > + ctx->fwspec->param[0] = hwirq;
> > + ctx->fwspec->param[1] = acpi_dev_get_irq_type(triggering, polarity);
> > + ctx->fwspec->param_count = 2;
> > +}
>
> > +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
> > +{
> > + struct irq_fwspec fwspec;
> > + struct irq_domain *domain;
> > + unsigned long flags;
> > + int rc;
> > +
> > + rc = acpi_irq_parse_one(handle, index, &fwspec, &flags);
> > + if (rc)
> > + return rc;
> > +
> > + domain = irq_find_matching_fwnode(fwspec.fwnode, DOMAIN_BUS_ANY);
> > + if (!domain)
> > + return -EPROBE_DEFER;
> > +
> > + rc = irq_create_fwspec_mapping(&fwspec);
> > + if (rc <= 0)
>
> Is rc = 0 an error?
Yes.
> > + return -EINVAL;
> > +
> > + res->start = rc;
> > + res->end = rc;
> > + res->flags = flags;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_irq_get);
>
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
>
> > r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> > + if (r && r->flags & IORESOURCE_DISABLED && has_acpi_companion(&dev->dev)) {
> > + int ret;
> > +
> > + ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> > + if (ret)
> > + return ret;
> > + }
>
> > +#ifdef CONFIG_ACPI_GENERIC_GSI
>
> #if IS_ENABLED()
>
> > +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res);
> > +#else
> > +static inline int acpi_irq_get(acpi_handle handle, unsigned int index,
> > + struct resource *res)
>
> Perhaps
>
> static inline
> int ...
It is late -rc5 and notwithstanding cosmetics changes, can we make
progress with this patch series or not please ?
Thanks,
Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V11 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
Date: Thu, 26 Jan 2017 10:15:21 +0000 [thread overview]
Message-ID: <20170126101521.GA10324@red-moon> (raw)
In-Reply-To: <CAHp75VeYxfuMuaZCMk+MYdxLTs7cCa6j6M7Ot3XnwMmeHP7kBA@mail.gmail.com>
On Thu, Jan 26, 2017 at 03:01:18AM +0200, Andy Shevchenko wrote:
> On Fri, Jan 20, 2017 at 4:34 AM, Agustin Vega-Frias
> <agustinv@codeaurora.org> wrote:
> > ACPI extended IRQ resources may contain a ResourceSource to specify
> > an alternate interrupt controller. Introduce acpi_irq_get and use it
> > to implement ResourceSource/IRQ domain mapping.
> >
> > The new API is similar to of_irq_get and allows re-initialization
> > of a platform resource from the ACPI extended IRQ resource, and
> > provides proper behavior for probe deferral when the domain is not
> > yet present when called.
>
> > +static struct fwnode_handle *
> > +acpi_get_irq_source_fwhandle(const struct acpi_resource_source *source)
> > +{
> > + struct fwnode_handle *result = NULL;
> > + struct acpi_device *device;
> > + struct acpi_hardware_id *hwid;
> > + struct acpi_device_id *devid;
> > + acpi_handle handle;
> > + acpi_status status;
> > +
> > + if (!source->string_length)
> > + return acpi_gsi_domain_id;
> > +
> > + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> > + if (WARN_ON(ACPI_FAILURE(status)))
> > + return NULL;
> > +
> > + device = acpi_bus_get_acpi_device(handle);
> > + if (WARN_ON(!device))
> > + return NULL;
> > +
>
> > + list_for_each_entry(hwid, &device->pnp.ids, list) {
>
> > + for (devid = &__dsdt_irqchip_acpi_probe_table;
> > + devid < &__dsdt_irqchip_acpi_probe_table_end; devid++) {
> > + if (devid->id && !strcmp(devid->id, hwid->id)) {
> > + result = &device->fwnode;
> > + break;
> > + }
> > + }
>
> Looks like a candidate for linker table API. (I recommend to Cc Luis
> for this part)
This linker table entry scheme is just an optimization and should
not gate the series.
> > + }
>
> > +/**
> > + * acpi_irq_parse_one_match - Handle a matching IRQ resource.
> > + * @fwnode: matching fwnode
> > + * @hwirq: hardware IRQ number
> > + * @triggering: triggering attributes of hwirq
> > + * @polarity: polarity attributes of hwirq
> > + * @polarity: polarity attributes of hwirq
> > + * @shareable: shareable attributes of hwirq
> > + * @ctx: acpi_irq_parse_one_ctx updated by this function
> > + *
> > + * Description:
> > + * Handle a matching IRQ resource by populating the given ctx with
> > + * the information passed.
> > + */
> > +static inline void acpi_irq_parse_one_match(struct fwnode_handle *fwnode,
> > + u32 hwirq, u8 triggering,
> > + u8 polarity, u8 shareable,
> > + struct acpi_irq_parse_one_ctx *ctx)
> > +{
>
> > + if (!fwnode)
> > + return;
>
> > + ctx->rc = 0;
>
> Perhaps ctx->rc = fwnode ? 0 : -EINVAL; ?
>
> > + *ctx->res_flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> > + ctx->fwspec->fwnode = fwnode;
> > + ctx->fwspec->param[0] = hwirq;
> > + ctx->fwspec->param[1] = acpi_dev_get_irq_type(triggering, polarity);
> > + ctx->fwspec->param_count = 2;
> > +}
>
> > +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
> > +{
> > + struct irq_fwspec fwspec;
> > + struct irq_domain *domain;
> > + unsigned long flags;
> > + int rc;
> > +
> > + rc = acpi_irq_parse_one(handle, index, &fwspec, &flags);
> > + if (rc)
> > + return rc;
> > +
> > + domain = irq_find_matching_fwnode(fwspec.fwnode, DOMAIN_BUS_ANY);
> > + if (!domain)
> > + return -EPROBE_DEFER;
> > +
> > + rc = irq_create_fwspec_mapping(&fwspec);
> > + if (rc <= 0)
>
> Is rc = 0 an error?
Yes.
> > + return -EINVAL;
> > +
> > + res->start = rc;
> > + res->end = rc;
> > + res->flags = flags;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_irq_get);
>
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
>
> > r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> > + if (r && r->flags & IORESOURCE_DISABLED && has_acpi_companion(&dev->dev)) {
> > + int ret;
> > +
> > + ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> > + if (ret)
> > + return ret;
> > + }
>
> > +#ifdef CONFIG_ACPI_GENERIC_GSI
>
> #if IS_ENABLED()
>
> > +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res);
> > +#else
> > +static inline int acpi_irq_get(acpi_handle handle, unsigned int index,
> > + struct resource *res)
>
> Perhaps
>
> static inline
> int ...
It is late -rc5 and notwithstanding cosmetics changes, can we make
progress with this patch series or not please ?
Thanks,
Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Agustin Vega-Frias <agustinv@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Marc Zyngier <marc.zyngier@arm.com>,
Timur Tabi <timur@codeaurora.org>,
Christopher Covington <cov@codeaurora.org>,
Andy Gross <agross@codeaurora.org>,
harba@codeaurora.org, Jon Masters <jcm@redhat.com>,
msalter@redhat.com, mlangsdo@redhat.com,
Al Stone <ahs3@redhat.com>,
astone@redhat.com, Graeme Gregory <graeme.gregory@linaro.org>,
guohanjun@huawei.com,
Charles Garcia-Tobin <charles.garcia-tobin@arm.com>
Subject: Re: [PATCH V11 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
Date: Thu, 26 Jan 2017 10:15:21 +0000 [thread overview]
Message-ID: <20170126101521.GA10324@red-moon> (raw)
In-Reply-To: <CAHp75VeYxfuMuaZCMk+MYdxLTs7cCa6j6M7Ot3XnwMmeHP7kBA@mail.gmail.com>
On Thu, Jan 26, 2017 at 03:01:18AM +0200, Andy Shevchenko wrote:
> On Fri, Jan 20, 2017 at 4:34 AM, Agustin Vega-Frias
> <agustinv@codeaurora.org> wrote:
> > ACPI extended IRQ resources may contain a ResourceSource to specify
> > an alternate interrupt controller. Introduce acpi_irq_get and use it
> > to implement ResourceSource/IRQ domain mapping.
> >
> > The new API is similar to of_irq_get and allows re-initialization
> > of a platform resource from the ACPI extended IRQ resource, and
> > provides proper behavior for probe deferral when the domain is not
> > yet present when called.
>
> > +static struct fwnode_handle *
> > +acpi_get_irq_source_fwhandle(const struct acpi_resource_source *source)
> > +{
> > + struct fwnode_handle *result = NULL;
> > + struct acpi_device *device;
> > + struct acpi_hardware_id *hwid;
> > + struct acpi_device_id *devid;
> > + acpi_handle handle;
> > + acpi_status status;
> > +
> > + if (!source->string_length)
> > + return acpi_gsi_domain_id;
> > +
> > + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> > + if (WARN_ON(ACPI_FAILURE(status)))
> > + return NULL;
> > +
> > + device = acpi_bus_get_acpi_device(handle);
> > + if (WARN_ON(!device))
> > + return NULL;
> > +
>
> > + list_for_each_entry(hwid, &device->pnp.ids, list) {
>
> > + for (devid = &__dsdt_irqchip_acpi_probe_table;
> > + devid < &__dsdt_irqchip_acpi_probe_table_end; devid++) {
> > + if (devid->id && !strcmp(devid->id, hwid->id)) {
> > + result = &device->fwnode;
> > + break;
> > + }
> > + }
>
> Looks like a candidate for linker table API. (I recommend to Cc Luis
> for this part)
This linker table entry scheme is just an optimization and should
not gate the series.
> > + }
>
> > +/**
> > + * acpi_irq_parse_one_match - Handle a matching IRQ resource.
> > + * @fwnode: matching fwnode
> > + * @hwirq: hardware IRQ number
> > + * @triggering: triggering attributes of hwirq
> > + * @polarity: polarity attributes of hwirq
> > + * @polarity: polarity attributes of hwirq
> > + * @shareable: shareable attributes of hwirq
> > + * @ctx: acpi_irq_parse_one_ctx updated by this function
> > + *
> > + * Description:
> > + * Handle a matching IRQ resource by populating the given ctx with
> > + * the information passed.
> > + */
> > +static inline void acpi_irq_parse_one_match(struct fwnode_handle *fwnode,
> > + u32 hwirq, u8 triggering,
> > + u8 polarity, u8 shareable,
> > + struct acpi_irq_parse_one_ctx *ctx)
> > +{
>
> > + if (!fwnode)
> > + return;
>
> > + ctx->rc = 0;
>
> Perhaps ctx->rc = fwnode ? 0 : -EINVAL; ?
>
> > + *ctx->res_flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> > + ctx->fwspec->fwnode = fwnode;
> > + ctx->fwspec->param[0] = hwirq;
> > + ctx->fwspec->param[1] = acpi_dev_get_irq_type(triggering, polarity);
> > + ctx->fwspec->param_count = 2;
> > +}
>
> > +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
> > +{
> > + struct irq_fwspec fwspec;
> > + struct irq_domain *domain;
> > + unsigned long flags;
> > + int rc;
> > +
> > + rc = acpi_irq_parse_one(handle, index, &fwspec, &flags);
> > + if (rc)
> > + return rc;
> > +
> > + domain = irq_find_matching_fwnode(fwspec.fwnode, DOMAIN_BUS_ANY);
> > + if (!domain)
> > + return -EPROBE_DEFER;
> > +
> > + rc = irq_create_fwspec_mapping(&fwspec);
> > + if (rc <= 0)
>
> Is rc = 0 an error?
Yes.
> > + return -EINVAL;
> > +
> > + res->start = rc;
> > + res->end = rc;
> > + res->flags = flags;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_irq_get);
>
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
>
> > r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> > + if (r && r->flags & IORESOURCE_DISABLED && has_acpi_companion(&dev->dev)) {
> > + int ret;
> > +
> > + ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> > + if (ret)
> > + return ret;
> > + }
>
> > +#ifdef CONFIG_ACPI_GENERIC_GSI
>
> #if IS_ENABLED()
>
> > +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res);
> > +#else
> > +static inline int acpi_irq_get(acpi_handle handle, unsigned int index,
> > + struct resource *res)
>
> Perhaps
>
> static inline
> int ...
It is late -rc5 and notwithstanding cosmetics changes, can we make
progress with this patch series or not please ?
Thanks,
Lorenzo
next prev parent reply other threads:[~2017-01-26 10:15 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 2:34 [PATCH V11 0/3] irqchip: qcom: Add IRQ combiner driver Agustin Vega-Frias
2017-01-20 2:34 ` Agustin Vega-Frias
2017-01-20 2:34 ` Agustin Vega-Frias
2017-01-20 2:34 ` [PATCH V11 1/3] ACPI: Generic GSI: Do not attempt to map non-GSI IRQs during bus scan Agustin Vega-Frias
2017-01-20 2:34 ` Agustin Vega-Frias
2017-01-20 2:34 ` Agustin Vega-Frias
2017-01-26 0:47 ` Andy Shevchenko
2017-01-26 0:47 ` Andy Shevchenko
2017-01-26 0:47 ` Andy Shevchenko
2017-01-31 22:00 ` Rafael J. Wysocki
2017-01-31 22:00 ` Rafael J. Wysocki
2017-01-31 22:00 ` Rafael J. Wysocki
2017-01-20 2:34 ` [PATCH V11 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping Agustin Vega-Frias
2017-01-20 2:34 ` Agustin Vega-Frias
2017-01-20 2:34 ` Agustin Vega-Frias
2017-01-20 12:21 ` Lorenzo Pieralisi
2017-01-20 12:21 ` Lorenzo Pieralisi
2017-01-26 1:01 ` Andy Shevchenko
2017-01-26 1:01 ` Andy Shevchenko
2017-01-26 1:01 ` Andy Shevchenko
2017-01-26 10:15 ` Lorenzo Pieralisi [this message]
2017-01-26 10:15 ` Lorenzo Pieralisi
2017-01-26 10:15 ` Lorenzo Pieralisi
2017-01-26 10:38 ` Andy Shevchenko
2017-01-26 10:38 ` Andy Shevchenko
2017-01-26 10:38 ` Andy Shevchenko
2017-01-26 10:43 ` Rafael J. Wysocki
2017-01-26 10:43 ` Rafael J. Wysocki
2017-01-26 10:43 ` Rafael J. Wysocki
2017-01-26 13:48 ` Lorenzo Pieralisi
2017-01-26 13:48 ` Lorenzo Pieralisi
2017-01-26 13:48 ` Lorenzo Pieralisi
2017-01-20 2:34 ` [PATCH V11 3/3] irqchip: qcom: Add IRQ combiner driver Agustin Vega-Frias
2017-01-20 2:34 ` Agustin Vega-Frias
2017-01-20 2:34 ` Agustin Vega-Frias
2017-01-26 0:44 ` Andy Shevchenko
2017-01-26 0:44 ` Andy Shevchenko
2017-01-26 0:44 ` Andy Shevchenko
2017-02-02 22:20 ` Agustin Vega-Frias
2017-02-02 22:20 ` Agustin Vega-Frias
2017-01-20 3:02 ` [PATCH V11 0/3] " Rafael J. Wysocki
2017-01-20 3:02 ` Rafael J. Wysocki
2017-01-20 3:02 ` Rafael J. Wysocki
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=20170126101521.GA10324@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=agross@codeaurora.org \
--cc=agustinv@codeaurora.org \
--cc=ahs3@redhat.com \
--cc=andy.shevchenko@gmail.com \
--cc=astone@redhat.com \
--cc=cov@codeaurora.org \
--cc=graeme.gregory@linaro.org \
--cc=guohanjun@huawei.com \
--cc=harba@codeaurora.org \
--cc=jason@lakedaemon.net \
--cc=jcm@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mlangsdo@redhat.com \
--cc=msalter@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=timur@codeaurora.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.