From: kgunda@codeaurora.org
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Shawn Guo <shawnguo@kernel.org>,
gregkh@linuxfoundation.org, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Abhijeet Dharmapurikar <adharmap@codeaurora.org>,
David Collins <collinsd@codeaurora.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
linux-arm-msm-owner@vger.kernel.org
Subject: Re: [PATCH V2] spmi: pmic-arb: Enforce the ownership check optionally
Date: Wed, 23 Aug 2017 18:27:22 +0530 [thread overview]
Message-ID: <632ae6ac77226ed528dbc50b2ca9ac9f@codeaurora.org> (raw)
In-Reply-To: <20170822203132.GC21656@codeaurora.org>
On 2017-08-23 02:01, Stephen Boyd wrote:
> On 08/22, Shawn Guo wrote:
>> On Mon, Aug 21, 2017 at 04:18:58PM -0700, Stephen Boyd wrote:
>> > On 08/18/2017 08:28 AM, Kiran Gunda wrote:
>> > > The peripheral ownership check is not necessary on single master
>> > > platforms. Hence, enforce the peripheral ownership check optionally.
>> > >
>> > > Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
>> > > Tested-by: Shawn Guo <shawnguo@kernel.org>
>> > > ---
>> >
>> > This sounds like a band-aid. Isn't the gpio driver going to keep probing
>> > all the pins that are not supposed to be accessed due to security
>> > constraints? What exactly is failing in the gpio case?
>>
>> There is a platform_irq_count() call in pinctrl-spmi-gpio probe
>> function. Due to the owner check in spmi-pmic-arb IRQ domain
>> qpnpint_irq_domain_dt_translate() function, the call will return irq
>> number as zero and cause pmic_gpio_probe() fail with -EINVAL error.
>>
>> [ 1.608516] [<ffff00000860e51c>]
>> qpnpint_irq_domain_dt_translate+0x168/0x194
>> [ 1.613557] [<ffff000008117040>]
>> irq_create_fwspec_mapping+0x17c/0x2d8
>> [ 1.620672] [<ffff000008117200>] irq_create_of_mapping+0x64/0x74
>> [ 1.627008] [<ffff0000087b4fac>] of_irq_get+0x54/0x64
>> [ 1.633169] [<ffff00000856b824>] platform_get_irq+0x20/0x150
>> [ 1.638117] [<ffff00000856b97c>] platform_irq_count+0x28/0x44
>> [ 1.643850] [<ffff0000083cf12c>] pmic_gpio_probe+0x50/0x544
>>
>
> Hmm. Ok. I guess platform_irq_count() has to go and create irq
> mappings if they haven't been created yet and that then causes us
> to check if we can even get the interrupt for this particular
> irq? There are some interrupt lines that are not routed to the
> application processor in the system, so the irq_ee (irq execution
> environment) is different. This check is there to avoid creating
> flow handlers for irqs that can't be triggered.
>
> I can see how trying to request that irq doesn't make sense,
> because it won't ever happen. But preventing that from being
> translated is confusing. Perhaps we can move the check for irq_ee
> to the irq_request_resources() callback in the irqchip? That way,
> we can fail installing the flow handler for the interrupt we
> can't ever receive, but otherwise translate the interrupt number
> so we can keep counting them.
>
Hi Stephen,
The idea to move the ownership check to irq_request_resources sounds
good.
I am dropping this patch and sent the new patch to move the irq
ownership to
irq_request_resource. Following is the patchwork link.
Shawn, can you please give a try with it?
https://patchwork.kernel.org/patch/9917315/
> Also, I see that on v4.13-rc series the read/write checks are
> causing the led driver to fail in a different way:
>
> spmi spmi-0: error: impermissible write to peripheral sid:0
> addr:0xc040
> qcom-spmi-gpio 200f000.spmi:pm8916@0:gpios@c000: write 0x40 failed
> leds-gpio soc:leds: Error applying setting, reverse things back
> spmi spmi-0: error: impermissible write to peripheral sid:0
> addr:0xc041
> qcom-spmi-gpio 200f000.spmi:pm8916@0:gpios@c000: write 0x41 failed
> leds-gpio: probe of soc:leds failed with error -1
>
> Are you seeing similar behavior?
With the new patch series these errors will go away, as we are removing
the ownership
checks from the read/write path.
next prev parent reply other threads:[~2017-08-23 12:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-18 15:28 [PATCH V2] spmi: pmic-arb: Enforce the ownership check optionally Kiran Gunda
[not found] ` <1503070110-15018-1-git-send-email-kgunda-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-08-21 23:18 ` Stephen Boyd
2017-08-22 8:55 ` Shawn Guo
2017-08-22 20:31 ` Stephen Boyd
2017-08-23 12:57 ` kgunda [this message]
2017-08-24 12:18 ` Shawn Guo
2017-08-24 18:37 ` Stephen Boyd
2017-08-25 7:47 ` Shawn Guo
2017-08-25 23:18 ` Stephen Boyd
[not found] ` <20170825231818.GP21656-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-08-26 3:46 ` Shawn Guo
2017-08-30 21:02 ` Stephen Boyd
2017-08-31 8:37 ` Shawn Guo
2017-09-01 1:30 ` Stephen Boyd
[not found] ` <20170901013048.GK21656-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-09-01 3:00 ` Shawn Guo
2017-08-28 8:27 ` Fenglin Wu
[not found] ` <93b8935e-061f-ba3a-ee36-8ffbc8230bcc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-08-28 14:47 ` Shawn Guo
2017-08-22 9:01 ` Shawn Guo
2017-08-28 11:53 ` Greg KH
2017-08-28 14:08 ` Shawn Guo
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=632ae6ac77226ed528dbc50b2ca9ac9f@codeaurora.org \
--to=kgunda@codeaurora.org \
--cc=adharmap@codeaurora.org \
--cc=collinsd@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=shawnguo@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 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).