From: "Anna, Suman" <s-anna-l0cyMroinI0@public.gmane.org>
To: florian.vaussard-p8DiymsW2f8@public.gmane.org,
"Joerg Roedel" <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
"Tony Lindgren" <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
"Benoît Cousson"
<bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
"linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 1/7] iommu/omap: Do bus_set_iommu() only if probe() succeeds
Date: Mon, 23 Dec 2013 17:35:29 -0600 [thread overview]
Message-ID: <52B8C8C1.8080101@ti.com> (raw)
In-Reply-To: <52B8A5F8.3000706-p8DiymsW2f8@public.gmane.org>
Hi Florian,
>>
>> On 12/17/2013 06:53 AM, Florian Vaussard wrote:
>>> Currently, bus_set_iommu() is done in omap_iommu_init(). However,
>>> omap_iommu_probe() can fail in a number of ways, leaving the platform
>>> bus with a dangling reference to a non-initialized iommu. Perform
>>> bus_set_iommu() only if omap_iommu_probe() succeed.
>>
>> Can you clarify a bit more on what kind of issues you were seeing
>> specifically? In general, there can be multiple instances of the iommu,
>> so setting it in probe may not be fixing whatever issue you were seeing.
>> The current OMAP3 code has only the ISP MMU enabled, but there is also
>> another one for the IVA MMU (currently not configured by default).
>> Moving the bus_set_iommu to probe makes sense if only one iommu is
>> present, so this patch may not be needed at all.
>>
>
> If omap_iommu_probe() fails, the init will have called bus_set_iommu()
> anyways. Thus, when a driver request the iommu by calling
> iommu_domain_alloc(), it will succeed (but iommu_attach_device() will
> fail if I remember).
Yeah, thats the behavior I expected anyway.
> Leaving a driver with a dangling reference to
> a phantom iommu is not good IMHO. It will lead to strange behaviours
> one day or another.
>
> As for the multiple iommu case, as I do not think it is currently
> possible, as bus_type (in this case &platform_bus_type) has only
> one struct iommu_ops. bus_set_iommu() will return EBUSY on the
> second call. Am I missing something?
What I meant was the problem you cited will still exist, say if ISP MMU
probe failed, but the IVA MMU probe succeeded. The bus_set_iommu() can
only be called once anyway, so moving it from init to probe would not
help much.
regards
Suman
>
>> Also, the main change in this patch is moving the bus_set_iommu from
>> omap_iommu_init to omap_iommu_probe, so you should probably leave out
>> moving the function. The omap_iommu_probe function would anyway need
>> conversion to using devm_ functions.
>>
>
> This was my first try also, but as bus_set_iommu() needs omap_iommu_ops
> (itself depending on several functions), its call must come after the
> declaration of omap_iommu_ops. Thus I moved omap_iommu_probe() after
> the declaration of omap_iommu_ops. But I can probably use a forward
> declaration for omap_iommu_ops, this would be better.
>
> Indeed, we can also convert to devm_.
>
> Regards,
>
> Florian
>
WARNING: multiple messages have this Message-ID (diff)
From: s-anna@ti.com (Anna, Suman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/7] iommu/omap: Do bus_set_iommu() only if probe() succeeds
Date: Mon, 23 Dec 2013 17:35:29 -0600 [thread overview]
Message-ID: <52B8C8C1.8080101@ti.com> (raw)
In-Reply-To: <52B8A5F8.3000706@epfl.ch>
Hi Florian,
>>
>> On 12/17/2013 06:53 AM, Florian Vaussard wrote:
>>> Currently, bus_set_iommu() is done in omap_iommu_init(). However,
>>> omap_iommu_probe() can fail in a number of ways, leaving the platform
>>> bus with a dangling reference to a non-initialized iommu. Perform
>>> bus_set_iommu() only if omap_iommu_probe() succeed.
>>
>> Can you clarify a bit more on what kind of issues you were seeing
>> specifically? In general, there can be multiple instances of the iommu,
>> so setting it in probe may not be fixing whatever issue you were seeing.
>> The current OMAP3 code has only the ISP MMU enabled, but there is also
>> another one for the IVA MMU (currently not configured by default).
>> Moving the bus_set_iommu to probe makes sense if only one iommu is
>> present, so this patch may not be needed at all.
>>
>
> If omap_iommu_probe() fails, the init will have called bus_set_iommu()
> anyways. Thus, when a driver request the iommu by calling
> iommu_domain_alloc(), it will succeed (but iommu_attach_device() will
> fail if I remember).
Yeah, thats the behavior I expected anyway.
> Leaving a driver with a dangling reference to
> a phantom iommu is not good IMHO. It will lead to strange behaviours
> one day or another.
>
> As for the multiple iommu case, as I do not think it is currently
> possible, as bus_type (in this case &platform_bus_type) has only
> one struct iommu_ops. bus_set_iommu() will return EBUSY on the
> second call. Am I missing something?
What I meant was the problem you cited will still exist, say if ISP MMU
probe failed, but the IVA MMU probe succeeded. The bus_set_iommu() can
only be called once anyway, so moving it from init to probe would not
help much.
regards
Suman
>
>> Also, the main change in this patch is moving the bus_set_iommu from
>> omap_iommu_init to omap_iommu_probe, so you should probably leave out
>> moving the function. The omap_iommu_probe function would anyway need
>> conversion to using devm_ functions.
>>
>
> This was my first try also, but as bus_set_iommu() needs omap_iommu_ops
> (itself depending on several functions), its call must come after the
> declaration of omap_iommu_ops. Thus I moved omap_iommu_probe() after
> the declaration of omap_iommu_ops. But I can probably use a forward
> declaration for omap_iommu_ops, this would be better.
>
> Indeed, we can also convert to devm_.
>
> Regards,
>
> Florian
>
WARNING: multiple messages have this Message-ID (diff)
From: "Anna, Suman" <s-anna@ti.com>
To: florian.vaussard@epfl.ch, "Joerg Roedel" <joro@8bytes.org>,
"Tony Lindgren" <tony@atomide.com>,
"Benoît Cousson" <bcousson@baylibre.com>
Cc: Rob Herring <rob.herring@calxeda.com>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>, Rob Landley <rob@landley.net>,
Grant Likely <grant.likely@linaro.org>,
Hiroshi Doyu <hdoyu@nvidia.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/7] iommu/omap: Do bus_set_iommu() only if probe() succeeds
Date: Mon, 23 Dec 2013 17:35:29 -0600 [thread overview]
Message-ID: <52B8C8C1.8080101@ti.com> (raw)
In-Reply-To: <52B8A5F8.3000706@epfl.ch>
Hi Florian,
>>
>> On 12/17/2013 06:53 AM, Florian Vaussard wrote:
>>> Currently, bus_set_iommu() is done in omap_iommu_init(). However,
>>> omap_iommu_probe() can fail in a number of ways, leaving the platform
>>> bus with a dangling reference to a non-initialized iommu. Perform
>>> bus_set_iommu() only if omap_iommu_probe() succeed.
>>
>> Can you clarify a bit more on what kind of issues you were seeing
>> specifically? In general, there can be multiple instances of the iommu,
>> so setting it in probe may not be fixing whatever issue you were seeing.
>> The current OMAP3 code has only the ISP MMU enabled, but there is also
>> another one for the IVA MMU (currently not configured by default).
>> Moving the bus_set_iommu to probe makes sense if only one iommu is
>> present, so this patch may not be needed at all.
>>
>
> If omap_iommu_probe() fails, the init will have called bus_set_iommu()
> anyways. Thus, when a driver request the iommu by calling
> iommu_domain_alloc(), it will succeed (but iommu_attach_device() will
> fail if I remember).
Yeah, thats the behavior I expected anyway.
> Leaving a driver with a dangling reference to
> a phantom iommu is not good IMHO. It will lead to strange behaviours
> one day or another.
>
> As for the multiple iommu case, as I do not think it is currently
> possible, as bus_type (in this case &platform_bus_type) has only
> one struct iommu_ops. bus_set_iommu() will return EBUSY on the
> second call. Am I missing something?
What I meant was the problem you cited will still exist, say if ISP MMU
probe failed, but the IVA MMU probe succeeded. The bus_set_iommu() can
only be called once anyway, so moving it from init to probe would not
help much.
regards
Suman
>
>> Also, the main change in this patch is moving the bus_set_iommu from
>> omap_iommu_init to omap_iommu_probe, so you should probably leave out
>> moving the function. The omap_iommu_probe function would anyway need
>> conversion to using devm_ functions.
>>
>
> This was my first try also, but as bus_set_iommu() needs omap_iommu_ops
> (itself depending on several functions), its call must come after the
> declaration of omap_iommu_ops. Thus I moved omap_iommu_probe() after
> the declaration of omap_iommu_ops. But I can probably use a forward
> declaration for omap_iommu_ops, this would be better.
>
> Indeed, we can also convert to devm_.
>
> Regards,
>
> Florian
>
next prev parent reply other threads:[~2013-12-23 23:35 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-17 12:53 [PATCH 0/7] Fix omap-iommu probe and convert to DT for 3.14 Florian Vaussard
2013-12-17 12:53 ` Florian Vaussard
2013-12-17 12:53 ` [PATCH 1/7] iommu/omap: Do bus_set_iommu() only if probe() succeeds Florian Vaussard
2013-12-17 12:53 ` Florian Vaussard
[not found] ` <1387284818-28739-2-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
2013-12-23 19:02 ` Anna, Suman
2013-12-23 19:02 ` Anna, Suman
2013-12-23 19:02 ` Anna, Suman
[not found] ` <52B888C2.8040303-l0cyMroinI0@public.gmane.org>
2013-12-23 21:07 ` Florian Vaussard
2013-12-23 21:07 ` Florian Vaussard
2013-12-23 21:07 ` Florian Vaussard
[not found] ` <52B8A5F8.3000706-p8DiymsW2f8@public.gmane.org>
2013-12-23 23:35 ` Anna, Suman [this message]
2013-12-23 23:35 ` Anna, Suman
2013-12-23 23:35 ` Anna, Suman
[not found] ` <52B8C8C1.8080101-l0cyMroinI0@public.gmane.org>
2014-01-15 17:12 ` Florian Vaussard
2014-01-15 17:12 ` Florian Vaussard
2014-01-15 17:12 ` Florian Vaussard
2013-12-17 12:53 ` [PATCH 2/7] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL Florian Vaussard
2013-12-17 12:53 ` Florian Vaussard
[not found] ` <1387284818-28739-3-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
2013-12-23 18:45 ` Anna, Suman
2013-12-23 18:45 ` Anna, Suman
2013-12-23 18:45 ` Anna, Suman
2013-12-17 12:53 ` [PATCH 3/7] iommu/omap: Convert to devicetree Florian Vaussard
2013-12-17 12:53 ` Florian Vaussard
[not found] ` <1387284818-28739-4-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
2013-12-23 19:48 ` Anna, Suman
2013-12-23 19:48 ` Anna, Suman
2013-12-23 19:48 ` Anna, Suman
[not found] ` <52B89394.5060902-l0cyMroinI0@public.gmane.org>
2013-12-23 21:17 ` Florian Vaussard
2013-12-23 21:17 ` Florian Vaussard
2013-12-23 21:17 ` Florian Vaussard
[not found] ` <52B8A87F.7080100-p8DiymsW2f8@public.gmane.org>
2013-12-23 23:42 ` Anna, Suman
2013-12-23 23:42 ` Anna, Suman
2013-12-23 23:42 ` Anna, Suman
2014-01-02 0:13 ` Laurent Pinchart
2014-01-02 0:13 ` Laurent Pinchart
2014-01-02 0:13 ` Laurent Pinchart
2014-01-02 1:01 ` Sebastian Reichel
2014-01-02 1:01 ` Sebastian Reichel
[not found] ` <20140102010150.GA9933-SfvFxonMDyemK9LvCR3Hrw@public.gmane.org>
2014-01-15 17:16 ` Florian Vaussard
2014-01-15 17:16 ` Florian Vaussard
2014-01-15 17:16 ` Florian Vaussard
2013-12-17 12:53 ` [PATCH 4/7] iommu/omap: Allow enable/disable even without pdata Florian Vaussard
2013-12-17 12:53 ` Florian Vaussard
[not found] ` <1387284818-28739-5-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
2013-12-23 19:05 ` Anna, Suman
2013-12-23 19:05 ` Anna, Suman
2013-12-23 19:05 ` Anna, Suman
[not found] ` <52B88990.5020807-l0cyMroinI0@public.gmane.org>
2013-12-23 21:19 ` Florian Vaussard
2013-12-23 21:19 ` Florian Vaussard
2013-12-23 21:19 ` Florian Vaussard
2013-12-17 12:53 ` [PATCH 5/7] ARM: dts: Complete data for isp iommu Florian Vaussard
2013-12-17 12:53 ` Florian Vaussard
[not found] ` <1387284818-28739-6-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
2013-12-23 19:12 ` Anna, Suman
2013-12-23 19:12 ` Anna, Suman
2013-12-23 19:12 ` Anna, Suman
[not found] ` <52B88B1A.40506-l0cyMroinI0@public.gmane.org>
2013-12-23 21:34 ` Florian Vaussard
2013-12-23 21:34 ` Florian Vaussard
2013-12-23 21:34 ` Florian Vaussard
2013-12-24 0:10 ` Anna, Suman
2013-12-24 0:10 ` Anna, Suman
2013-12-17 12:53 ` [PATCH 6/7] ARM: OMAP2+: Remove legacy data from hwmod for omap3 " Florian Vaussard
2013-12-17 12:53 ` Florian Vaussard
[not found] ` <1387284818-28739-7-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
2013-12-23 19:08 ` Anna, Suman
2013-12-23 19:08 ` Anna, Suman
2013-12-23 19:08 ` Anna, Suman
[not found] ` <52B88A49.9020402-l0cyMroinI0@public.gmane.org>
2013-12-23 21:36 ` Florian Vaussard
2013-12-23 21:36 ` Florian Vaussard
2013-12-23 21:36 ` Florian Vaussard
[not found] ` <52B8ACED.1030209-p8DiymsW2f8@public.gmane.org>
2013-12-23 23:28 ` Anna, Suman
2013-12-23 23:28 ` Anna, Suman
2013-12-23 23:28 ` Anna, Suman
2013-12-17 12:53 ` [PATCH 7/7] ARM: OMAP2+: Remove platform-specific omap-iommu Florian Vaussard
2013-12-17 12:53 ` Florian Vaussard
[not found] ` <1387284818-28739-1-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
2013-12-23 18:52 ` [PATCH 0/7] Fix omap-iommu probe and convert to DT for 3.14 Anna, Suman
2013-12-23 18:52 ` Anna, Suman
2013-12-23 18:52 ` Anna, Suman
[not found] ` <52B8866D.9060100-l0cyMroinI0@public.gmane.org>
2013-12-23 20:51 ` Florian Vaussard
2013-12-23 20:51 ` Florian Vaussard
2013-12-23 20:51 ` Florian Vaussard
[not found] ` <52B8A26A.3000905-p8DiymsW2f8@public.gmane.org>
2013-12-23 23:54 ` Anna, Suman
2013-12-23 23:54 ` Anna, Suman
2013-12-23 23:54 ` Anna, Suman
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=52B8C8C1.8080101@ti.com \
--to=s-anna-l0cymroini0@public.gmane.org \
--cc=bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=florian.vaussard-p8DiymsW2f8@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.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.