From: Suman Anna <s-anna@ti.com>
To: Philipp Zabel <p.zabel@pengutronix.de>,
Tero Kristo <t-kristo@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: Wed, 21 Aug 2019 10:45:45 -0500 [thread overview]
Message-ID: <5e82199f-2f75-ee05-ba65-1595d0526572@ti.com> (raw)
In-Reply-To: <1566400237.4193.15.camel@pengutronix.de>
On 8/21/19 10:10 AM, Philipp Zabel wrote:
> On Tue, 2019-08-20 at 11:47 -0500, Suman Anna wrote:
>> On 8/20/19 2:37 AM, Tero Kristo wrote:
>>> On 20.8.2019 2.01, Suman Anna wrote:
>>>> Hi Tero,
>>>>
>>>> On 8/19/19 4:32 AM, Tero Kristo wrote:
> [...]
>>>>>>> +{
>>>>>>> + struct omap_reset_data *reset;
>>>>>>> +
>>>>>>> + /*
>>>>>>> + * Check if we have resets. If either rstctl or rstst is
>>>>>>> + * non-zero, we have reset registers in place. Additionally
>>>>>>> + * the flag OMAP_PRM_NO_RSTST implies that we have resets.
>>>>>>> + */
>>>>>>> + if (!prm->data->rstctl && !prm->data->rstst &&
>>>>>>> + !(prm->data->flags & OMAP_PRM_NO_RSTST))
>>>>>>> + return 0;
>>>>>>> +
>>>>>>> + reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
>>>>>>> + if (!reset)
>>>>>>> + return -ENOMEM;
>>>>>>> +
>>>>>>> + reset->rcdev.owner = THIS_MODULE;
>>>>>>> + reset->rcdev.ops = &omap_reset_ops;
>>>>>>> + reset->rcdev.of_node = pdev->dev.of_node;
>>>>>>> + reset->rcdev.nr_resets = OMAP_MAX_RESETS;
>>>>
>>>> Suggest adding a number of resets to prm->data, and using it so that we
>>>> don't even entertain any resets beyond the actual number of resets.
>>>
>>> Hmm why bother? Accessing a stale reset bit will just cause access to a
>>> reserved bit in the reset register, doing basically nothing. Also, this
>>> would not work for am3/am4 wkup, as there is a single reset bit at an
>>> arbitrary position.
>>
>> The generic convention seems to be defining a reset id value defined
>> from include/dt-bindings/reset/ that can be used to match between the
>> dt-nodes and the reset-controller driver.
>>
>> Philipp,
>> Any comments?
>
> Are there only reset bits and reserved bits in the range accessible by
> [0..OMAP_MAX_RESETS] or are ther bits with another function as well?
Thanks Philipp, these are just reset bits and reserved bits.
> If the latter is the case, I would prefer enumerating the resets in a
> dt-bindings header, with the driver containing an enum -> reg/bit
> position lookup table.
>
> 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?
regards
Suman
_______________________________________________
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-21 15:46 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 [this message]
2019-08-21 18:15 ` Tero Kristo
2019-08-23 8:50 ` Philipp Zabel
2019-08-23 11:27 ` Tero Kristo
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=5e82199f-2f75-ee05-ba65-1595d0526572@ti.com \
--to=s-anna@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=ssantosh@kernel.org \
--cc=t-kristo@ti.com \
--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).