linux-kernel - Re: [PATCH 1/2] dt-bindings: reset: Updated binding for Versal-NET reset driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jul 2023 09:10:53 +0200
From:   Michal Simek <michal.simek@....com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Conor Dooley <conor@...nel.org>,
        Piyush Mehta <piyush.mehta@....com>
Cc:     robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, p.zabel@...gutronix.de,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        git@....com
Subject: Re: [PATCH 1/2] dt-bindings: reset: Updated binding for Versal-NET
 reset driver

On 7/17/23 22:47, Krzysztof Kozlowski wrote:
> On 17/07/2023 20:40, Conor Dooley wrote:
>> On Mon, Jul 17, 2023 at 04:53:47PM +0530, Piyush Mehta wrote:
>>> Added documentation and Versal-NET reset indices to describe about
>>> Versal-Net reset driver bindings.
>>>
>>> In Versal-NET all reset indices includes Class, SubClass, Type, Index
>>> information whereas class refers to clock, reset, power etc.,
>>> Underlying firmware in Versal have such classification and expects
>>> the ID to be this way.
>>> [13:0] - Index bits
>>> [19:14] - Type bits
>>> [25:20] - SubClass bits
>>> [31:26] - Class bits.
>>
>> Riight.. I'm not sure that describing these as "indices" is really all
>> that valid, given only 13:0 are actually the index.
>> I'd be inclined to say that the type/class/subclass stuff should not be
>> part of the dt-bindings, and instead looked up inside the driver
>> depending on the index.
>>
>> Hopefully Rob or Krzysztof can comment further.
> 
> This confuses me as well. I don't understand why do you need it in the
> bindings. Nothing uses these values, so storing them as bindings seems
> pointless.

Power Management team wants to use these NodeID with format describe above to 
identify that elements. And I already told them that ID (0-max) translation to 
internal NodeID format should be done in firmware but they don't pretty much 
agree with it.

 From DT binding perspective I think it doesn't really matter if numbers are 
from 0 to max or they are from random high number to another random number 
without step equal to 1.
And it is driver implementation detail if driver itself is checking that 
requested ID is bigger than number of pins passed.

In connection to reset driver in Linux.

Core has:
static int of_reset_simple_xlate(struct reset_controller_dev *rcdev,
                                  const struct of_phandle_args *reset_spec)
{
         if (reset_spec->args[0] >= rcdev->nr_resets)
                 return -EINVAL;

         return reset_spec->args[0];
}

/**
  * reset_controller_register - register a reset controller device
  * @rcdev: a pointer to the initialized reset controller device
  */
int reset_controller_register(struct reset_controller_dev *rcdev)
{
         if (!rcdev->of_xlate) {
                 rcdev->of_reset_n_cells = 1;
                 rcdev->of_xlate = of_reset_simple_xlate;
         }
...

And zynqmp reset driver already defines of_xlate function that's why checking 
against nr_resets is not done as is visible from code below.

static int zynqmp_reset_of_xlate(struct reset_controller_dev *rcdev,
                                  const struct of_phandle_args *reset_spec)
{
         return reset_spec->args[0];
}

And actually Xilinx Versal platform is using this for a while and you can find 
IDs description here.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/dt-bindings/reset/xlnx-versal-resets.h?h=v6.5-rc2

Xilinx ZynqMP is using IDs from 0 to 119
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/dt-bindings/reset/xlnx-zynqmp-resets.h?h=v6.5-rc2

but IDs itself are shifted by 1000:
include/linux/firmware/xlnx-zynqmp.h:217:  ZYNQMP_PM_RESET_START = 1000,
#define ZYNQMP_RESET_ID ZYNQMP_PM_RESET_START

static const struct zynqmp_reset_soc_data zynqmp_reset_data = {
         .reset_id = ZYNQMP_RESET_ID,
         .num_resets = ZYNQMP_NR_RESETS,
};

static int zynqmp_reset_assert(struct reset_controller_dev *rcdev,
                                unsigned long id)
{
         struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);

         return zynqmp_pm_reset_assert(priv->data->reset_id + id,
                                       PM_RESET_ACTION_ASSERT);
}

That numbers in DT are virtual no matter if you use ID from 0 to max or random 
values it is up to code to handle them. Checking nr_pins against ID is done in 
core but it is up to drivers.
In our case that IDs are coming from firmware and driver itself is just matching 
them.
At the end of day pretty much IDs in header can be from 0 to max and conversion 
to IDs can be done in the driver itself or in driver probe firmware can be 
requested to provide IDs with specific call.

Thanks,
Michal