[PATCH 07/11] sysreset: socfpga: Use parent device for reading base address

[Paweł Anikiel]

On Mon, Apr 11, 2022 at 8:36 PM Simon Glass <sjg at chromium.org> wrote:
>
> On Fri, 1 Apr 2022 at 06:44, Paweł Anikiel <pan at semihalf.com> wrote:
> >
> > This driver is a child of the rstmgr driver, both of which share the
> > same devicetree node. As a result, passing the child's udevice pointer
> > to dev_read_addr_ptr results in a failure of reading the #address-cells
> > property. Use the parent udevice pointer instead.
> >
> > Signed-off-by: Paweł Anikiel <pan at semihalf.com>
> > ---
> >  drivers/sysreset/sysreset_socfpga.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass <sjg at chromium.org>
>
> >
> > diff --git a/drivers/sysreset/sysreset_socfpga.c b/drivers/sysreset/sysreset_socfpga.c
> > index e38296ac3f..9b62dd5eab 100644
> > --- a/drivers/sysreset/sysreset_socfpga.c
> > +++ b/drivers/sysreset/sysreset_socfpga.c
> > @@ -40,7 +40,7 @@ static int socfpga_sysreset_probe(struct udevice *dev)
>
> Perhaps this function
> >  {
> >         struct socfpga_sysreset_data *data = dev_get_priv(dev);
> >
> > -       data->rstmgr_base = dev_read_addr_ptr(dev);
> > +       data->rstmgr_base = dev_read_addr_ptr(dev_get_parent(dev));
> >         return 0;
> >  }
> >
> > --
> > 2.35.1.1094.g7c7d902a7c-goog
> >
>
> This is pretty odd and I think it could use a comment, particularly as
> this driver doesn't seem to be in the device tree.

It does get bound to a devicetree node by a different driver:
reset-socfpga (drivers/reset/reset-socfpga.c:141):
        /*
         * The sysreset driver does not have a device node, so bind it here.
         * Bind it to the node, too, so that it can get its base address.
         */
        ret = device_bind_driver_to_node(dev, "socfpga_sysreset", "sysreset",
                                         dev_ofnode(dev), &sys_child);
However, this makes it so that dev_read_addr_ptr doesn't behave the way
one would think, hence this patch.

It is pretty odd, it seems to be caused by the fact that Arria 10's
peripheral reset manager
is also responsible for system reset (see "ctrl" register in rst_mgr's
register map):
https://www.intel.com/content/www/us/en/programmable/hps/arria-10/hps.html#topic/sfo1429890591861.html
Because of this, the two drivers have to share the same devicetree node.

Do you see a different way this could be fixed? If not, I will add
a comment with an explanation similar to the commit message.

Regards,
Paweł