Received: by 10.223.185.116 with SMTP id b49csp3920065wrg; Tue, 13 Feb 2018 09:45:33 -0800 (PST) X-Google-Smtp-Source: AH8x2242+zL6ORWmn/pwKuU9K3ylwif12fT3AWrLC9R0ox61SgJhRdIMwPGo4lC5eqhC4TutfTCc X-Received: by 2002:a17:902:d20a:: with SMTP id t10-v6mr1846530ply.257.1518543933702; Tue, 13 Feb 2018 09:45:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518543933; cv=none; d=google.com; s=arc-20160816; b=FnOjqy+jeQRaut451nV9n+6q6Ns67kqZql2CvaIUP17pKHzqZ4vGebLLLInJGUn3oP Db8kcb9p9UhrIigw1VS0Ay4ZpIlWjMDJfReBaTPd/lHkKndgniF+MuGK0nwzR+i+eoyV tEAtTbXFia1eEoNrZzMQqLKw3qoxOfu95wjcDRLyMLiPHnBqFIo04F3r0F5ncHJgFSSz bw6RT1speyuAPeRusQgOU8iv2sdSGcTTzhQvVEDydCLLQ1MN6XZfIwRxCDtXqn231tzs AvxKSDOg6xl2tC08kPPZDUUx3N3xMzaOE65OWo1Voh9eas0yqw3M5XPhbhgLJrchv4dw 9Drg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=bf9a8mIsaT/9Qx2wM14n2BWf/tRz2jPdtikFZGb6MYM=; b=FzVHXx0CV8TNVkeR030L1K+ei5bq5nIJmapmyLUzX1tfj+3zCrtzRYquYS4+yvfkmh TvJZ7Q4I1YanGyupw1Teq4laglK8z1iBp10+oKpRbzFUhdZ+2Fp2AXZ9faZ8/5Rm21+I f/u3SpyIp8lh1JbjaTI/pvPWkZM8/2Mr/3+wEVmhH0My/wMpPmF7SMccteQ868TtlaUc 9dnzz/+cbunN+6YSOFhz7fl+CmQnqsj8sGR/Ypd9XD2UQqKAjbCZYD7lWSud+VOJlehZ DhfcosnWk01PULKug+7asJWZll86lasEofyErv/+G0EYHqK0o4xkfMzQObt03gCY+ZKA US1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=Ms/v4MMB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x88si1485751pfj.307.2018.02.13.09.45.18; Tue, 13 Feb 2018 09:45:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=Ms/v4MMB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965339AbeBMRno (ORCPT + 99 others); Tue, 13 Feb 2018 12:43:44 -0500 Received: from mail-ot0-f194.google.com ([74.125.82.194]:34095 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934279AbeBMRnn (ORCPT ); Tue, 13 Feb 2018 12:43:43 -0500 Received: by mail-ot0-f194.google.com with SMTP id l10so18020785oth.1 for ; Tue, 13 Feb 2018 09:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bf9a8mIsaT/9Qx2wM14n2BWf/tRz2jPdtikFZGb6MYM=; b=Ms/v4MMBR7o3sYCV7Tz8wCQ4CjfRBOHAal2LL6lRc3EwgcDTl2a5IDTrCfsjNKFz7c FJGWXpdVuOUfSxvrLxoZp1L+c6ndK3MP7xwtxL+wWlQEc2zyTrzjMJZ0DP1Kd2uap0ee USioG2mMaDZbCo14q9rTrMfL5yN4y2RkI/Yl6SSev8zRq8PUF7A7ZRPwVnxVDMaDnNGo te7ESjNGz+RtB0/xRd3E3ZiOCiDfzJq2WIYimqGsMsDcWo4+lgVuGnfHQKHqnLTSz+Fc UvacHO/Q436rOgsHlysg1EZu2lEe2rgP8GpJqtGqTKLGXvbWdD+CRPbM4i+WvGwJatvX 3CSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bf9a8mIsaT/9Qx2wM14n2BWf/tRz2jPdtikFZGb6MYM=; b=k1VcQY3knasT/JtX4bpY+X+qiwuolH+l+bMSI5V6sKGMpZOklVpNJy03NJtWNoD+26 LL8OCE/7Q7c9wwfWxNqbMM/aUsoh6pw2dBRyFUTClvfu26NlGy2gYzlFCWB7mhXum56K zeltyjTjxdCCHVQBWIjBGzjug88KUnipNKJooo26HwBe3BcL+Vf3M/Xo0uFUGUHHw0a+ F4SWwuXs7R2rgPejCYVMEUbpZDTmn374O02WuDAm3+49lEiC0gmp4Q55Km0b/+1uy3LX HT8yapLUHqlEnSQXqTvjBlqtBj0hE4h1SBWHAIRb7YlBcTYfAwf40BWASHHrPwO0vpIG VyUA== X-Gm-Message-State: APf1xPC8Jjf3rGQXZjB1aSPSE7DoCAQSsGT7/8rBchnSU5McDywhshnE AoN24JKV7Kx8YMPfZYTYs3zhZ2jwxcD/ea3IFxOrEySU X-Received: by 10.157.19.74 with SMTP id q10mr1636676otq.56.1518543822171; Tue, 13 Feb 2018 09:43:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.42.71 with HTTP; Tue, 13 Feb 2018 09:43:41 -0800 (PST) In-Reply-To: References: <20180213152524.16620-1-brgl@bgdev.pl> From: Bartosz Golaszewski Date: Tue, 13 Feb 2018 18:43:41 +0100 Message-ID: Subject: Re: [PATCH] reset: add support for non-DT systems To: David Lechner Cc: Philipp Zabel , Linux Kernel Mailing List , Bartosz Golaszewski , Sekhar Nori , Kevin Hilman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-02-13 18:17 GMT+01:00 David Lechner : > On 02/13/2018 09:25 AM, Bartosz Golaszewski wrote: >> >> From: Bartosz Golaszewski >> >> 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 and an additional, optional identifier >> string. >> >> 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[] = { >> [FOO_RESET] = { .dev = "foo", .id = "foo_id" }, >> [BAR_RESET] = { .dev = "bar", .id = NULL }, >> { } >> }; >> >> where FOO_RESET and BAR_RESET will correspond with the id parameters >> of reset callbacks. >> >> Cc: Sekhar Nori >> Cc: Kevin Hilman >> Cc: David Lechner >> Signed-off-by: Bartosz Golaszewski >> --- > > > Looks good to me. I just made a few very minor comments. I will > try to use this in PSC driver later today. > Cool, if it works for you - feel free to include it in your series. > >> drivers/reset/core.c | 43 >> ++++++++++++++++++++++++++++++++++++++-- >> include/linux/reset-controller.h | 13 ++++++++++++ >> 2 files changed, 54 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/reset/core.c b/drivers/reset/core.c >> index da4292e9de97..ba7011c6e06f 100644 >> --- a/drivers/reset/core.c >> +++ b/drivers/reset/core.c >> @@ -493,12 +493,51 @@ struct reset_control *__of_reset_control_get(struct >> device_node *node, >> } >> EXPORT_SYMBOL_GPL(__of_reset_control_get); >> +static struct reset_control * >> +__reset_control_get_lookup(struct device *dev, const char *id, > > > Based on the name of the function, I expected this to return > struct reset_lookup. Perhaps __reset_control_lookup() or > __reset_control_match_lookup() would be a slightly better name? > > >> + bool shared, bool optional) >> +{ >> + struct reset_controller_dev *rcdev; >> + const char *dev_id = dev_name(dev); >> + struct reset_control *rstc = NULL; >> + const struct reset_lookup *lookup; >> + int index; >> + >> + mutex_lock(&reset_list_mutex); >> + >> + list_for_each_entry(rcdev, &reset_controller_list, list) { >> + if (!rcdev->lookup) >> + continue; >> + >> + lookup = rcdev->lookup; >> + for (index = 0; lookup->dev; index++, lookup++) { >> + if (strcmp(dev_id, lookup->dev)) >> + continue; >> + >> + if ((!id && !lookup->id) || >> + (id && lookup->id && !strcmp(id, lookup->id))) >> { >> + rstc = __reset_control_get_internal(rcdev, >> + index, >> shared); Ugh, I noticed that this needs a break here, otherwise we'll always iterate over all the entries. >> + } >> + } >> + } >> + >> + mutex_unlock(&reset_list_mutex); >> + >> + if (!rstc) >> + return optional ? NULL : ERR_PTR(-ENOENT); >> + >> + return rstc; >> +} >> + >> struct reset_control *__reset_control_get(struct device *dev, const char >> *id, >> int index, bool shared, bool >> optional) >> { >> if (dev->of_node) >> - return __of_reset_control_get(dev->of_node, id, index, >> shared, >> - optional); >> + return __of_reset_control_get(dev->of_node, id, >> + index, shared, optional); > > > I don't understand why this line is changed. It is just being rearranged? > Yes, but I can leave it out of this patch. > >> + else >> + return __reset_control_get_lookup(dev, id, shared, >> optional); >> return optional ? NULL : ERR_PTR(-EINVAL); >> } >> diff --git a/include/linux/reset-controller.h >> b/include/linux/reset-controller.h >> index adb88f8cefbc..0c081336e08b 100644 >> --- a/include/linux/reset-controller.h >> +++ b/include/linux/reset-controller.h >> @@ -22,6 +22,17 @@ struct reset_control_ops { >> int (*status)(struct reset_controller_dev *rcdev, unsigned long >> id); >> }; >> +/** >> + * struct reset_lookup - a single entry in a reset lookup table >> + * >> + * @dev: name of the device associated with this reset >> + * @id: additional reset identifier (if the device uses multiple reset >> lines) >> + */ >> +struct reset_lookup { >> + const char *dev; >> + const char *id; >> +}; >> + >> struct module; >> struct device_node; >> struct of_phandle_args; >> @@ -34,6 +45,7 @@ struct of_phandle_args; >> * @list: internal list of reset controller devices >> * @reset_control_head: head of internal list of requested reset >> controls >> * @of_node: corresponding device tree node as phandle target >> + * @lookup: array of lookup entries associated with this request >> controller > > > Might be nice to mention that this array must end with an empty struct (i.e. > lookup->dev == NULL) > > >> * @of_reset_n_cells: number of cells in reset line specifiers >> * @of_xlate: translation function to translate from specifier as found >> in the >> * device tree to id as given to the reset control ops >> @@ -45,6 +57,7 @@ struct reset_controller_dev { >> struct list_head list; >> struct list_head reset_control_head; >> struct device_node *of_node; >> + const struct reset_lookup *lookup; >> int of_reset_n_cells; >> int (*of_xlate)(struct reset_controller_dev *rcdev, >> const struct of_phandle_args *reset_spec); >> > Bartosz