Received: by 10.223.185.116 with SMTP id b49csp4016597wrg; Tue, 13 Feb 2018 11:18:52 -0800 (PST) X-Google-Smtp-Source: AH8x226Icc2BT+g5fulOEleFXRRWIbvgjzrlmLb719xj2/SFmbemGBJKhS2IMkBMW9ZKPYJMAd2h X-Received: by 10.98.10.25 with SMTP id s25mr2230486pfi.137.1518549532281; Tue, 13 Feb 2018 11:18:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518549532; cv=none; d=google.com; s=arc-20160816; b=BJ2i5NjmAYYSG9YnSghGLnsWczXWtE8PzaX5lI2w2BCQplFWukwDlLFGeyTp3Ct2xt DxuBCj4KQHLOFydtRWJnc+bqDrRhGn3KG/Bg96/vYqtCMGP26cxToI/OFv2IWEIKuJG8 ctQ0r7Q21RVDtAdIUxuz2m0NaqXDnUmSUE77j6tqL4+8IbXPRHnTqsglFKyiC3HaTe2c +WRVTaX90GfXx5+rFnWtTtjSjrZ6CKR//3QOOhPJiniH/3oBkA1vZ7L1oOllNkQXXT7O JszpQyRPGT1K/pwPZcmkrG5v0GrcV2nEZjrnaJsc+2pqqs/K5VxylLBfF8bXGboF0hX+ BX/g== 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=74pSC7MUFyK3JGYHEL/KmS+2m0DqNhTsRqlhRyqowog=; b=yfEuKIj90Q644tcuB9Qa3dwsyE/a6C5ih1W+N6VnDcET3enbdgJGVfGN6yeVX7adNs 5cfj9rIFAQLLSGWrLw35pb4OrHZSZEzFmAhyTyR9N7YVD94K2hz/c/ZEHiTxEmR9hgAn Umv+WEzFQ8dCR7dam/AiNlr36RgvX/LvHyprb8r3LSOnsns8cpfIg4xTD4gVF09PNPlK kywi9JwrBaJAGLTizh5d3O43XI61+plH7zi57+3s+wgZLE+TJnuVzqJarf+WcCO4j+fz 5f9yjfzxfU/oNAbGOYXjfuNS+OZ0LK1mJcWogYm6G0s9x3Cam6rGcAiyHi6H3QRw1HgO v4eg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=awkk/U50; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m197si6887071pga.206.2018.02.13.11.18.37; Tue, 13 Feb 2018 11:18:52 -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=@gmail.com header.s=20161025 header.b=awkk/U50; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754259AbeBMTRg (ORCPT + 99 others); Tue, 13 Feb 2018 14:17:36 -0500 Received: from mail-qk0-f176.google.com ([209.85.220.176]:37102 "EHLO mail-qk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754221AbeBMTRe (ORCPT ); Tue, 13 Feb 2018 14:17:34 -0500 Received: by mail-qk0-f176.google.com with SMTP id c128so23748622qkb.4 for ; Tue, 13 Feb 2018 11:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=74pSC7MUFyK3JGYHEL/KmS+2m0DqNhTsRqlhRyqowog=; b=awkk/U50jS6YD4X4MTLDAwbvcf04y82jNEzVXm8U+OkUE6vwG9zH74/8RDjBw5/MsU nPujseHN0t+ham8ALr/lhDuowi8lbVwziazRq43tXJ9VK+G2zVbZdzGLaZezQs1U2Vm0 8k723JhsiXVrP2O+JK/UrPUIyc9ugY9Rv/2H75uFX2JyRMVfEN/RGLHnFnnzLN3hjCnk 0UYrBOrG1J0WGcRDDOKIUL0qJwAona1wylz9s2/c/2aRiDffjTOYTSuDJTTAuxqcM9+n NGJNKQ6ZGSVhOJJild2XjbcQWvj7AKKtSSdRxVrmIG0nODFshDM+M1v5LhXSnweOKTD5 jr+A== 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=74pSC7MUFyK3JGYHEL/KmS+2m0DqNhTsRqlhRyqowog=; b=AESTqOiPEJxAH/kkpYvB59vsaGvLj5+CZNVNzwFtPazHNfhaOnIEw2/A4Z09e2Cu6A H8U/zJy3bE6be7Ie8WmUhDyQ43BIzCujjhKKr4yZsNtGYVsRqiG7LgiooYd6Teo6FM4y K4ncV0vLpKC7+Wlqi8HiT1pclHKppc6oVewybuPN3csfnspkawC3ea+88GdEmmZp99/B nzzv8Kt3zCDlSoM0YQ7LbkIG+Glbcy1Ig3T2bES5cBfuluXnDsOZZSBP9Vdx+1jZPBYN 2ri1VGtN5TbuoswoXk1KTQukaE3ZaYTFPYer2hCad04zH3F2GySkcEydJIKfq1nmB0qG fINg== X-Gm-Message-State: APf1xPBa7uYl/6OrxXyKfyFdt9c+g2YgDw0ziORJ2C8aLwReUp2qxgXw uqNYJFNslkt4DADf792tcI83mpbObcHTZY23r2k= X-Received: by 10.55.136.131 with SMTP id k125mr3430622qkd.319.1518549454048; Tue, 13 Feb 2018 11:17:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.195.82 with HTTP; Tue, 13 Feb 2018 11:17:33 -0800 (PST) In-Reply-To: <20180213183946.1662-1-brgl@bgdev.pl> References: <20180213183946.1662-1-brgl@bgdev.pl> From: Andy Shevchenko Date: Tue, 13 Feb 2018 21:17:33 +0200 Message-ID: Subject: Re: [PATCH v2] reset: add support for non-DT systems To: Bartosz Golaszewski Cc: Philipp Zabel , Linux Kernel Mailing List , Bartosz Golaszewski , Sekhar Nori , Kevin Hilman , David Lechner 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 On Tue, Feb 13, 2018 at 8:39 PM, 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. > +static struct reset_control * > +__reset_control_get_from_lookup(struct device *dev, const char *id, > + 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); > + break; > + } Wouldn't be slightly more readable if (id && lookup->id) { if (strcmp(id, lookup->id)) continue; } else if (id || lookup->id) { continue; } rstc = __reset_control_get_internal(rcdev, index, shared); break; > + } > + } > + > + mutex_unlock(&reset_list_mutex); > + > + if (!rstc) > + return optional ? NULL : ERR_PTR(-ENOENT); Isn't simpler if (!optional && !rstc) // or other way around, depending which might be more offten return ERR_PTR(...); > + return rstc; > +} -- With Best Regards, Andy Shevchenko