From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 278B6DDA9; Mon, 26 Feb 2024 00:34:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708907656; cv=none; b=YkZ9bGrqqEjwTOrNrmBwO/7/Isn1TApKYVtxbopIFzcqdXybn8ObrSZ7aYPlw8VjDyelfKg3YlP9sgiDg4mOQj9DIESBmxEoxHxH2ttabObSZlgNk9KmToxZHsEJ5ejGvVBSPr+XN0uFiXh/YtlofZlNnlmo6YGdjbN+CGrxqxA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708907656; c=relaxed/simple; bh=54BOPxkMLzdRKYevCC6yKEk91ZN6DktUcQnOZ91yBos=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KOFdPv8dz1FTIAiHEO44iNnX/8l8Tm+bE7RsHSeyG+l8fD/ol59zmvNza/mEO3SN5Y+JpODIKa8wDTvqfdBbbI5UwiuKM/LVRDthe2yDlZxwTDzW+Uyb75w6TyY48++r8MKisPnPuc9gW63xd7FgJetzL7kOvMaKXpEEgd/7+7c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.96.2) (envelope-from ) id 1reOVA-0001je-1q; Mon, 26 Feb 2024 00:05:48 +0000 Date: Mon, 26 Feb 2024 00:05:40 +0000 From: Daniel Golle To: Richard Weinberger Cc: Miquel Raynal , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-mtd , devicetree , linux-kernel Subject: Re: [PATCH v7 7/7] mtd: ubi: provide NVMEM layer over UBI volumes Message-ID: References: <82ceb13954f7e701bf47c112333e7b15a57fc360.1702952891.git.daniel@makrotopia.org> <20240219120156.383a1427@xps-13> <1209094181.98490.1708899174329.JavaMail.zimbra@nod.at> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1209094181.98490.1708899174329.JavaMail.zimbra@nod.at> Hi Richard, On Sun, Feb 25, 2024 at 11:12:54PM +0100, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > > Von: "Miquel Raynal" > > An: "Daniel Golle" > > CC: "richard" , "Vignesh Raghavendra" , "Rob Herring" , "Krzysztof > > Kozlowski" , "Conor Dooley" , "linux-mtd" > > , "devicetree" , "linux-kernel" > > > > Gesendet: Montag, 19. Februar 2024 12:01:56 > > Betreff: Re: [PATCH v7 7/7] mtd: ubi: provide NVMEM layer over UBI volumes > > > Hi Daniel, > > > > daniel@makrotopia.org wrote on Tue, 19 Dec 2023 02:33:48 +0000: > > > >> In an ideal world we would like UBI to be used where ever possible on a > >> NAND chip. And with UBI support in ARM Trusted Firmware and U-Boot it > >> is possible to achieve an (almost-)all-UBI flash layout. Hence the need > >> for a way to also use UBI volumes to store board-level constants, such > >> as MAC addresses and calibration data of wireless interfaces. > >> > >> Add UBI volume NVMEM driver module exposing UBI volumes as NVMEM > >> providers. Allow UBI devices to have a "volumes" firmware subnode with > >> volumes which may be compatible with "nvmem-cells". > >> Access to UBI volumes via the NVMEM interface at this point is > >> read-only, and it is slow, opening and closing the UBI volume for each > >> access due to limitations of the NVMEM provider API. > > > > I don't feel qualified enough to review the other patches, however this > > one looks good to me. > > Finally(!), I had enough time to look. > Thanks for addressing all my comments form the previous series. > Patches applied. It's an enourmous coicident that you are writing just now that I found a sizeof(int)-related problem which triggers a compiler warning when building the UBI NVMEM provider on 32-bit platforms. I was just about to prepare an updated series. Literally in this minute. Should I still send the whole updates series or only the final patch (as the necessary change is there) or a follow-up patch fixing the original patch? > > I have only one tiny request, can you share the lockdep spalt > you encountered in ubi_notify_add() regarding mtd_table_mutex > and ubi_devices_mutex? The solutions looks okay to me, but > if you have more details that would be great. I will setup a test build to reproduce the original warning and let you know shortly. Cheers Daniel