From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 0CC647D00B for ; Tue, 28 Aug 2018 14:48:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727950AbeH1Sk0 (ORCPT ); Tue, 28 Aug 2018 14:40:26 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:33411 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727841AbeH1SkZ (ORCPT ); Tue, 28 Aug 2018 14:40:25 -0400 Received: by mail-wr1-f68.google.com with SMTP id v90-v6so1873992wrc.0 for ; Tue, 28 Aug 2018 07:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z8u4+QUscOOBbFDXMTgV8XJh97AeyBBGr/ABcvtAHYw=; b=FqifKzsMMib3ctgZCeV7WiuATY0pprQsExUPs6ehoIX8nKW6dkHIugKQ5ALxj9fzTj semUMHJQD4xO0FGE2R9jjVQhvs0U+y3/Ar4zPtZaecQ5NCPxENrjH82coW60TXc0doXE hwOHprv59DIPR3WxceqM/j7VUwFW9XGqx8Wvg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z8u4+QUscOOBbFDXMTgV8XJh97AeyBBGr/ABcvtAHYw=; b=K/FHCaAXI1k9PqDCia2q5zk2m9tzSHXYnTLERbvNBlotiFc+pc8aZ0WwcGr8vMIbrr CQm+yBTL+OeLfK36BKstRtTm2HY5MzMp7La2zvgH6Quo0jOWtOTMWe6G9rcKuUM1RyJ0 vEwIkWmO6nLXiXJw3GbtmDlI+zW9WyLhGuzplBnlg2Hqo5tdskZziSOPt5Zj5FCqlpSW xcEWZ9m9NBtukKtNn1Gei1kQYNF4+dSAiOB9r2Ex3v+KOuvGmMtLEUwhifBPqrbl0h+i 6vXfwIX2hvdlpeUWe2R7dBqi6JZBupgPm/2Nc4dbLCyGYq8Gf+ddQwSV+2jDo6vnkbF1 cgtA== X-Gm-Message-State: APzg51C7x9kLFDLBP/CXDU7F3o6du8Vhf7FBy4m2vRbm1a3oMkQNP47o d833jwafsRxoAVXxzpJG4v3gew== X-Google-Smtp-Source: ANB0VdYiLlA6hrkJyF271yXChKrIOtNQnbHSSQB4x/XcE3tRFJ1gX8pRZ6g3Znz28TUrj8CpC2GKgw== X-Received: by 2002:adf:93c2:: with SMTP id 60-v6mr1293010wrp.81.1535467703738; Tue, 28 Aug 2018 07:48:23 -0700 (PDT) Received: from [192.168.0.18] (cpc90716-aztw32-2-0-cust92.18-1.cable.virginm.net. [86.26.100.93]) by smtp.googlemail.com with ESMTPSA id g133-v6sm1928311wmf.44.2018.08.28.07.48.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 07:48:22 -0700 (PDT) Subject: Re: [PATCH v2 01/29] nvmem: add support for cell lookups To: Bartosz Golaszewski Cc: Boris Brezillon , Andrew Lunn , linux-doc , Sekhar Nori , Bartosz Golaszewski , linux-i2c , Mauro Carvalho Chehab , Rob Herring , Florian Fainelli , Kevin Hilman , Richard Weinberger , Russell King , Marek Vasut , Paolo Abeni , Dan Carpenter , Grygorii Strashko , David Lechner , Arnd Bergmann , Sven Van Asbroeck , "open list:MEMORY TECHNOLOGY..." , Linux-OMAP , Linux ARM , Ivan Khoronzhuk , Greg Kroah-Hartman , Jonathan Corbet , Linux Kernel Mailing List , Lukas Wunner , Naren , netdev , Alban Bedel , Andrew Morton , Brian Norris , David Woodhouse , "David S . Miller" References: <20180810080526.27207-1-brgl@bgdev.pl> <20180810080526.27207-2-brgl@bgdev.pl> <20180824170848.29594318@bbrezillon> <20180824152740.GD27483@lunn.ch> <20180825082722.567e8c9a@bbrezillon> <20180827110055.122988d0@bbrezillon> <8cb75723-dc87-f127-2aab-54dd0b08eee8@linaro.org> <916e3e89-82b3-0d52-2b77-4374261a9d0f@linaro.org> From: Srinivas Kandagatla Message-ID: <626e6122-2e58-3317-89b2-77959c9310f7@linaro.org> Date: Tue, 28 Aug 2018 15:48:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 28/08/18 15:41, Bartosz Golaszewski wrote: > 2018-08-28 15:45 GMT+02:00 Srinivas Kandagatla : >> >> ... >>> I would like to support an additional use case here: the provider is >>> generic and is not aware of its cells at all. Since the only way of >>> defining nvmem cells is through DT or nvmem_config, we lack a way to >>> allow machine code to define cells without the provider code being >>> aware. >> >> >> machine driver should be able to do >> nvmem_device_get() >> nvmem_add_cells() >> > > Indeed, I missed the fact that you can retrieve the nvmem device by > name. Except that we cannot know that the nvmem provider has been > registered yet when calling nvmem_device_get(). This could potentially > be solved by my other patch that adds notifiers to nvmem, but it would > require much more boilerplate code in every board file. I think that > removing nvmem_cell_info from nvmem_config and having external cell > definitions would be cleaner. Yes, notifiers would work! ... >>> >>> Yes, I would like to rework nvmem a bit. I don't see any non-DT users >>> defining nvmem-cells using nvmem_config. I think that what we need is >>> a way of specifying cell config outside of nvmem providers in some >>> kind of structures. These tables would reference the provider by name >>> and define the cells. Then we would have an additional lookup >>> structure which would associate the consumer (by dev_id and con_id, >>> where dev_id could optionally be NULL and where we would fall back to >>> using con_id only) and the nvmem provider + cell together. Similarly >>> to how GPIO consumers are associated with the gpiochip and hwnum. How >>> does it sound? >> >> Yes, sounds good. >> >> Correct me if am wrong! >> You should be able to add the new cells using struct nvmem_cell_info and add >> them to particular provider using nvmem_add_cells(). >> >> Sounds like thats exactly what nvmem_add_lookup_table() would look like. >> >> We should add new nvmem_device_cell_get(nvmem, conn_id) which would return >> nvmem cell which is specific to the provider. This cell can be used by the >> machine driver to read/write. > > Except that we could do it lazily - when the nvmem provider actually > gets registered instead of doing it right away and risking that the > device isn't even there yet. > Yes, it makes more sense to do it once the provider is actually present! >> >>>>> >>>>> BTW: of_nvmem_cell_get() seems to always allocate an nvmem_cell >>>>> instance even if the cell for this node was already added to the nvmem >>>>> device. >>>> >>>> >>>> I hope you got the reason why of_nvmem_cell_get() always allocates new >>>> instance for every get!! >>> >>> >>> >>> I admit I didn't test it, but just from reading the code it seems like >>> in nvmem_cell_get() for DT-users we'll always get to >>> of_nvmem_cell_get() and in there we always end up calling line 873: >>> cell = kzalloc(sizeof(*cell), GFP_KERNEL); >>> >> That is correct, this cell is created when we do a get and release when we >> do a put(). >> > > Shouldn't we add the cell to the list, and check first if it's there > and only create it if not? Yes I agree, duplicate entry checks are missing! --srini > > Bart >