On 02/19/2018 07:13 AM, Philipp Zabel wrote:
Hi Bartosz,

On Mon, 2018-02-19 at 13:34 +0100, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski <bgolaszew...@baylibre.com>

The reset framework only supports device-tree. There are some platforms
however, which need to use it even in legacy, board-file based mode.

An example of such architecture is the DaVinci family of SoCs which
supports both device tree and legacy boot modes and we don't want to
introduce any regressions.

We're currently working on converting the platform from its hand-crafted
clock API to using the common clock framework. Part of the overhaul will
be representing the chip's power sleep controller's reset lines using
the reset framework.

This changeset extends the core reset code with a new field in the
reset controller struct which contains an array of lookup entries. Each
entry contains the device name, an additional, optional identifier
string and the reset id number.

Drivers can register a set of reset lines using this lookup table and
concerned devices can access them using the regular reset_control API.

This new function is only called as a fallback in case the of_node
field is NULL and doesn't change anything for current users.

Tested with a dummy reset driver with several lookup entries.

An example lookup table can look like this:

static const struct reset_lookup foobar_reset_lookup[] = {
        { .dev = "foo",   .reset_id = "foo_id",    .id = 14 },
        { .dev = "bar",   .id = NULL,              .id = 3  },
        { }

Thank you for the patch. This is a useful addition, but the lookups
should be added in platform code, not by the reset controller driver.

I would prefer reset_lookups to follow the patterns set by the other
subsystem's lookup implementations:
clk, gpiod, phy, and pwm have lookups that can be created from platform
code, independently from the drivers (via clkdev_add_table,
gpiod_add_lookup_table, phy_create_lookup, and pwm_add_table).

Following this pattern would allow to support reset controllers that are
implemented as proper device drivers, and reset controllers that are
reused on multiple platforms.

When testing v2 of this series, I was thinking that having this sort
of separation would be better as well.

Reply via email to