From: Tero Kristo <t-kristo@ti.com>
To: Philipp Zabel <p.zabel@pengutronix.de>,
Suman Anna <s-anna@ti.com>, Keerthy <j-keerthy@ti.com>,
<ssantosh@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
<linux-omap@vger.kernel.org>, <robh+dt@kernel.org>
Cc: tony@atomide.com, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/8] soc: ti: add initial PRM driver with reset control support
Date: Fri, 23 Aug 2019 14:27:00 +0300 [thread overview]
Message-ID: <11f3c842-d90c-6923-2adf-0635d9e780bd@ti.com> (raw)
In-Reply-To: <1566550205.3023.4.camel@pengutronix.de>
On 23.8.2019 11.50, Philipp Zabel wrote:
> On Wed, 2019-08-21 at 21:15 +0300, Tero Kristo wrote:
>> On 21.8.2019 18.45, Suman Anna wrote:
>>> On 8/21/19 10:10 AM, Philipp Zabel wrote:
> [...]
>>>> In general, assuming the device tree contains no errors, this should not
>>>> matter much, but I think it is nice if the reset driver, even with a
>>>> misconfigured device tree, can't write into arbitrary bit fields.
>>>
>>> Tero,
>>> Can you add a check for this if possible?
>>
>> Well, I can enforce the usage of reset bit mapping, which I have already
>> implemented for some SoCs like am33xx. If the specific ID is not found,
>> I can bail out. So, basically in this example requesting reset at index
>> 3 would succeed, but it would fail for any other ID; this would be
>> direct HW bit mapping.
>
> That should be fine.
Ok, I am re-working it like this locally right now.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-23 11:27 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 7:48 [PATCH 0/8] soc: ti: Add OMAP PRM driver Tero Kristo
2019-08-07 7:48 ` [PATCH 1/8] dt-bindings: omap: add new binding for PRM instances Tero Kristo
2019-08-08 4:35 ` Keerthy
2019-08-19 9:28 ` Tero Kristo
2019-08-19 21:28 ` Suman Anna
2019-08-20 7:45 ` Tero Kristo
2019-08-07 7:48 ` [PATCH 2/8] soc: ti: add initial PRM driver with reset control support Tero Kristo
2019-08-08 5:26 ` Keerthy
2019-08-19 9:32 ` Tero Kristo
2019-08-19 23:01 ` Suman Anna
2019-08-20 7:37 ` Tero Kristo
2019-08-20 16:47 ` Suman Anna
2019-08-21 15:10 ` Philipp Zabel
2019-08-21 15:45 ` Suman Anna
2019-08-21 18:15 ` Tero Kristo
2019-08-23 8:50 ` Philipp Zabel
2019-08-23 11:27 ` Tero Kristo [this message]
2019-08-07 7:48 ` [PATCH 3/8] soc: ti: omap-prm: poll for reset complete during de-assert Tero Kristo
2019-08-07 7:48 ` [PATCH 4/8] soc: ti: omap-prm: add support for denying idle for reset clockdomain Tero Kristo
2019-08-19 23:16 ` Suman Anna
2019-08-20 7:51 ` Tero Kristo
2019-08-07 7:48 ` [PATCH 5/8] soc: ti: omap-prm: add omap4 PRM data Tero Kristo
2019-08-08 5:30 ` Keerthy
2019-08-19 9:32 ` Tero Kristo
2019-08-19 23:08 ` Suman Anna
2019-08-20 7:52 ` Tero Kristo
2019-08-20 17:23 ` Suman Anna
2019-08-21 6:38 ` Tero Kristo
2019-08-07 7:48 ` [PATCH 6/8] soc: ti: omap_prm: add data for am33xx Tero Kristo
2019-08-19 23:11 ` Suman Anna
2019-08-20 18:48 ` Suman Anna
2019-08-21 7:23 ` Tero Kristo
2019-08-21 15:49 ` Suman Anna
2019-08-07 7:48 ` [PATCH 7/8] soc: ti: omap-prm: add dra7 PRM data Tero Kristo
2019-08-19 23:12 ` Suman Anna
2019-08-20 19:03 ` Suman Anna
2019-08-21 7:36 ` Tero Kristo
2019-08-07 7:48 ` [PATCH 8/8] ARM: OMAP2+: pdata-quirks: add PRM data for reset support Tero Kristo
2019-08-19 23:20 ` [PATCH 0/8] soc: ti: Add OMAP PRM driver Suman Anna
2019-08-20 7:54 ` Tero Kristo
2019-08-20 16:51 ` Suman Anna
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=11f3c842-d90c-6923-2adf-0635d9e780bd@ti.com \
--to=t-kristo@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=j-keerthy@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=s-anna@ti.com \
--cc=ssantosh@kernel.org \
--cc=tony@atomide.com \
/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).