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@arm.com
Subject: Re: [PATCH V10 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
Date: Thu, 19 Jan 2017 12:36:08 +0000 [thread overview]
Message-ID: <20170119123608.GA3431@red-moon> (raw)
In-Reply-To: <CAHp75Vem=mCOGVoOpCJFYHcO17mJ9gexsQxa0Pjf4Lbt3hibRA@mail.gmail.com>
On Wed, Jan 18, 2017 at 09:45:56PM +0200, Andy Shevchenko wrote:
[...]
> > +/**
> > + * acpi_irq_get - Look for the ACPI IRQ resource with the given index and
> > + * use it to initialize the given Linux IRQ resource.
> > + * @handle ACPI device handle
> > + * @index ACPI IRQ resource index to lookup
> > + * @res Linux IRQ resource to initialize
>
> Ah, you missed colons after field names:
> * @field1:
>
> > + *
> > + * Return:
>
> Next line: 0 on success
>
> > + * -EINVAL if an error occurs
> > + * -EPROBE_DEFER if the IRQ lookup/conversion failed
> > + */
> > +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
> > +{
>
> > + int rc;
>
> Put this last in the definition block.
>
> > + struct irq_fwspec fwspec;
> > + struct irq_domain *domain;
> > + unsigned long flags;
> > +
> > + 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;
>
> Hmm... Could it be other issues here?
That's a good point. Here probing should be deferred only if we know a
driver capable of handling fwspec.fwnode will have a chance to be
probed/initialized eventually right (which basically means it is
compiled in the kernel and we hope it will probed successfully) ? I am
not sure there is an easy way to detect that in ACPI at the moment, I
suspect it is time we added a linker section (or augment the existing
one used for irqchip early MADT parsing - IRQCHIP_ACPI_DECLARE) for this
purpose I do not see any other option (apart from leaving devices in the
deferred probe list if a driver for the irqchip represented by
fwspec.fwnode is not present in the kernel, which is a bit sloppy, or
resorting to checking Kconfig entries to detect compile time enabled
irqchip drivers).
> > +
> > + rc = irq_create_fwspec_mapping(&fwspec);
> > + if (rc <= 0)
> > + return -EINVAL;
> > +
>
> > + res->start = rc;
> > + res->end = rc;
> > + res->flags = flags;
>
> Perhaps struct resource *r should be a parameter to acpi_irq_parse_one().
Yeah but then you would end up with flags initialized in
acpi_irq_parse_one() and the other resource params (ie start, end) here,
I do not think it is nicer.
Thanks,
Lorenzo
>
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_irq_get);
> > +
> > +/**
> > * acpi_set_irq_model - Setup the GSI irqdomain information
> > * @model: the value assigned to acpi_irq_model
> > * @fwnode: the irq_domain identifier for mapping and looking up
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index c4af003..61423d2 100644
> > --- 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 && ACPI_COMPANION(&dev->dev)) {
>
> has_acpi_companion() ?
>
> > + int ret;
> > +
> > + ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> > + if (ret)
> > + return ret;
> > + }
>
> > @@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
> > memset(&pd->dev.devres_head, 0, sizeof(pd->dev.devres_head));
> > }
> > }
> > -
>
> It doesn't belong here.
>
> --
> With Best Regards,
> Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V10 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
Date: Thu, 19 Jan 2017 12:36:08 +0000 [thread overview]
Message-ID: <20170119123608.GA3431@red-moon> (raw)
In-Reply-To: <CAHp75Vem=mCOGVoOpCJFYHcO17mJ9gexsQxa0Pjf4Lbt3hibRA@mail.gmail.com>
On Wed, Jan 18, 2017 at 09:45:56PM +0200, Andy Shevchenko wrote:
[...]
> > +/**
> > + * acpi_irq_get - Look for the ACPI IRQ resource with the given index and
> > + * use it to initialize the given Linux IRQ resource.
> > + * @handle ACPI device handle
> > + * @index ACPI IRQ resource index to lookup
> > + * @res Linux IRQ resource to initialize
>
> Ah, you missed colons after field names:
> * @field1:
>
> > + *
> > + * Return:
>
> Next line: 0 on success
>
> > + * -EINVAL if an error occurs
> > + * -EPROBE_DEFER if the IRQ lookup/conversion failed
> > + */
> > +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
> > +{
>
> > + int rc;
>
> Put this last in the definition block.
>
> > + struct irq_fwspec fwspec;
> > + struct irq_domain *domain;
> > + unsigned long flags;
> > +
> > + 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;
>
> Hmm... Could it be other issues here?
That's a good point. Here probing should be deferred only if we know a
driver capable of handling fwspec.fwnode will have a chance to be
probed/initialized eventually right (which basically means it is
compiled in the kernel and we hope it will probed successfully) ? I am
not sure there is an easy way to detect that in ACPI at the moment, I
suspect it is time we added a linker section (or augment the existing
one used for irqchip early MADT parsing - IRQCHIP_ACPI_DECLARE) for this
purpose I do not see any other option (apart from leaving devices in the
deferred probe list if a driver for the irqchip represented by
fwspec.fwnode is not present in the kernel, which is a bit sloppy, or
resorting to checking Kconfig entries to detect compile time enabled
irqchip drivers).
> > +
> > + rc = irq_create_fwspec_mapping(&fwspec);
> > + if (rc <= 0)
> > + return -EINVAL;
> > +
>
> > + res->start = rc;
> > + res->end = rc;
> > + res->flags = flags;
>
> Perhaps struct resource *r should be a parameter to acpi_irq_parse_one().
Yeah but then you would end up with flags initialized in
acpi_irq_parse_one() and the other resource params (ie start, end) here,
I do not think it is nicer.
Thanks,
Lorenzo
>
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_irq_get);
> > +
> > +/**
> > * acpi_set_irq_model - Setup the GSI irqdomain information
> > * @model: the value assigned to acpi_irq_model
> > * @fwnode: the irq_domain identifier for mapping and looking up
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index c4af003..61423d2 100644
> > --- 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 && ACPI_COMPANION(&dev->dev)) {
>
> has_acpi_companion() ?
>
> > + int ret;
> > +
> > + ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> > + if (ret)
> > + return ret;
> > + }
>
> > @@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
> > memset(&pd->dev.devres_head, 0, sizeof(pd->dev.devres_head));
> > }
> > }
> > -
>
> It doesn't belong here.
>
> --
> With Best Regards,
> Andy Shevchenko
next prev parent reply other threads:[~2017-01-19 12:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 19:04 [PATCH V10 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping Agustin Vega-Frias
2017-01-18 19:45 ` Andy Shevchenko
2017-01-18 19:45 ` Andy Shevchenko
2017-01-19 12:36 ` Lorenzo Pieralisi [this message]
2017-01-19 12:36 ` Lorenzo Pieralisi
2017-01-19 16:14 ` Agustin Vega-Frias
2017-01-19 16:14 ` Agustin Vega-Frias
2017-01-19 15:40 ` Agustin Vega-Frias
2017-01-19 15:40 ` Agustin Vega-Frias
-- strict thread matches above, loose matches on Subject: below --
2017-01-18 16:46 [PATCH V10 0/3] irqchip: qcom: Add IRQ combiner driver Agustin Vega-Frias
2017-01-18 16:46 ` [PATCH V10 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping Agustin Vega-Frias
2017-01-18 16:46 ` Agustin Vega-Frias
2017-01-18 16:46 ` Agustin Vega-Frias
2017-01-18 18:00 ` Andy Shevchenko
2017-01-18 18:00 ` Andy Shevchenko
2017-01-18 19:02 ` Agustin Vega-Frias
2017-01-18 19:02 ` Agustin Vega-Frias
2017-01-18 19:02 ` Agustin Vega-Frias
2017-01-31 22:10 ` Rafael J. Wysocki
2017-01-31 22:10 ` Rafael J. Wysocki
2017-01-31 22:10 ` Rafael J. Wysocki
2017-02-02 22:38 ` Agustin Vega-Frias
2017-02-02 22:38 ` Agustin Vega-Frias
2017-02-02 22:38 ` Agustin Vega-Frias
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=20170119123608.GA3431@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=charles.garcia-tobin@arm.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.