[{"id":3680357,"web_url":"http://patchwork.ozlabs.org/comment/3680357/","msgid":"","list_archive_url":null,"date":"2026-04-22T09:07:32","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":92191,"url":"http://patchwork.ozlabs.org/api/people/92191/","name":"Bartosz Golaszewski","email":"brgl@kernel.org"},"content":"On Tue, Apr 21, 2026 at 4:08 PM Marek Vasut wrote:\n>\n> Handle special-case of AT24 EEPROM described in DT, which contains both\n> \"read-only\" and \"wp-gpios\" properties. Interpret this configuration as\n> default read-only, but with the possibility of unlock via force_ro sysfs\n> attribute.\n>\n\nPatch looks ok code-wise but does this really make sense? If an EEPROM\nis read-only, we should forbid writes in the kernel. Which board uses\nit? Can we simply remove the read-only flag from DT?\n\nAdmittedly: the DT bindings do allow it as read-only and wp-gpios are\nnot mutually exclusive but I think it's more of an accidental omission\nthan a planned feature.\n\nBart","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=I7ZqF5h+;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17123-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"I7ZqF5h+\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g0tfh1Zpmz1yCv\n\tfor ; Wed, 22 Apr 2026 19:07:56 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id D1F20300CE65\n\tfor ; Wed, 22 Apr 2026 09:07:47 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 4C98D3C1401;\n\tWed, 22 Apr 2026 09:07:46 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id E93143B27EC\n\tfor ; Wed, 22 Apr 2026 09:07:45 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 8F4B5C2BCB4\n\tfor ; Wed, 22 Apr 2026 09:07:45 +0000 (UTC)","by mail-lj1-f171.google.com with SMTP id\n 38308e7fff4ca-38cc8708d76so44231311fa.3\n for ; Wed, 22 Apr 2026 02:07:45 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776848866; cv=none;\n b=S5Kg1F3pUjBgbnKokmbnpdh3kjSncG/r5y3BmSGaYO64D3QUVh8eEQXXyE8PEMETTSxlOsuX5GGnaGaQ1SbTflqlkC1rv1pfrp3FH0N9CUU2OH/Gq5m4v3Kaj4y2V25h4ehJlJYvxaz3tYNChPTvwDd139aafcburv7m/LJUtEI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776848866; c=relaxed/simple;\n\tbh=l1XwqDtKAXYajCf9ghnOjVigNNAL92jujTw6dHjG998=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=HkTzvdpiWGAIb5IdNDbkY5x3VFSXdoBWz+5wkCZr5MRhaDxr5Y/6mLGDzjWRlxl46jZZOQi9uxOigK+yS2yJJGIBu2ZhjlO8+D5WR1B6ZUXa8hjHgJmZIgj3B29sBO30lfukdrQ2vNlirTCkPsFxFh8KwYJ5khBcIQep7q6UWDI=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=I7ZqF5h+; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1776848865;\n\tbh=l1XwqDtKAXYajCf9ghnOjVigNNAL92jujTw6dHjG998=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=I7ZqF5h+6rX1+4f0PNChyCXnJLG9lLo05DNKav9yQv3HJKcGnTyozvBSxqb+ydGmW\n\t TO0f2eeFcDFQYnhuCcyrXLvfnZ4dzKRo/d994S7B6Bd6px/EE7S8wE2EDWAQ2v/Gc8\n\t QALlI1+/NhNx0GGFje48tLoZLhGwbHNbNucZNy8eNYZ/rb/4KGRgl+6dsJ8BiG3PhQ\n\t CVR08kJdubD+/fWsX014SyE3JFIygb9Pp5E6OSQoGBW0rsdKHILjWl+1OlhxwOGDJd\n\t AG4OdpcQEK5nA0w8MlatALh4pfBHGKnvTHuajMDnABwcOzQuGGacOUW8dwXnzW8gPV\n\t feZGlLvio1Hag==","X-Gm-Message-State":"AOJu0YzCX/3xMpJjaVMOmapZc7/7UHlabFSwu1huIi3L+FumuCs86Mx0\n\t1XBbJxUbkBkzgfGe6ctUSRXASDtcndfJ/QqrfTLsz27IQxKEQcKJwm6F21x8J/e1CTjWP+Hc/la\n\t3UFQgl0rAMBAVLP2nhI/FYbrlhGLchY0BzuScwPfuWw==","X-Received":"by 2002:a05:651c:420d:b0:38e:da87:ce3 with SMTP id\n 38308e7fff4ca-38eda871158mr42706671fa.23.1776848864232; Wed, 22 Apr 2026\n 02:07:44 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260421140755.54222-1-marex@nabladev.com>","In-Reply-To":"<20260421140755.54222-1-marex@nabladev.com>","From":"Bartosz Golaszewski ","Date":"Wed, 22 Apr 2026 11:07:32 +0200","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzAz-D97iW3JhzcFyiuF0lV4G1jR_LWWGU2qGTILq9KVbYJAE_N-yWssG9Q","Message-ID":"\n ","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","To":"Marek Vasut ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n\tGreg Kroah-Hartman ,\n Srinivas Kandagatla ,\n\tlinux-kernel@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3680689,"web_url":"http://patchwork.ozlabs.org/comment/3680689/","msgid":"<210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>","list_archive_url":null,"date":"2026-04-22T11:33:08","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":91452,"url":"http://patchwork.ozlabs.org/api/people/91452/","name":"Marek Vasut","email":"marex@nabladev.com"},"content":"On 4/22/26 11:07 AM, Bartosz Golaszewski wrote:\n> On Tue, Apr 21, 2026 at 4:08 PM Marek Vasut wrote:\n>>\n>> Handle special-case of AT24 EEPROM described in DT, which contains both\n>> \"read-only\" and \"wp-gpios\" properties. Interpret this configuration as\n>> default read-only, but with the possibility of unlock via force_ro sysfs\n>> attribute.\n>>\n> \n> Patch looks ok code-wise but does this really make sense? If an EEPROM\n> is read-only, we should forbid writes in the kernel. Which board uses\n> it? Can we simply remove the read-only flag from DT?\n\nCurrently I am not aware of any upstream users, I plan to introduce one \nonce this patch or some for of it lands.\n\nI have is an ID EEPROM which I would like to be able to program under \nspecial circumstances (hence the wp-gpios control) , but it should be by \ndefault read-only .\n\nIf I remove the read-only, then by default the EEPROM is read-write, \nwhich is undesired. If I remote wp-gpios then I loose access to the \nforce_ro attribute which controls the nWP GPIO from userspace, which is \nundesired.\n\nSo I think defining this special-case where wp-gpios and read-only are \nused together as default-read-only is sensible.\n\n> Admittedly: the DT bindings do allow it as read-only and wp-gpios are\n> not mutually exclusive but I think it's more of an accidental omission\n> than a planned feature.\nI think it is currently an undefined behavior, and this patch defines it.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=nabladev.com header.i=@nabladev.com header.a=rsa-sha256\n header.s=dkim header.b=aIpE0Krw;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17125-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=\"aIpE0Krw\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=178.251.229.89","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=nabladev.com"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g14RB3hhmz1yD5\n\tfor ; Thu, 23 Apr 2026 02:28:38 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 9A3B53006B45\n\tfor ; Wed, 22 Apr 2026 16:28:34 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id B90AC37C92E;\n\tWed, 22 Apr 2026 16:28:32 +0000 (UTC)","from mx.nabladev.com (mx.nabladev.com [178.251.229.89])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id EAE7937FF68;\n\tWed, 22 Apr 2026 16:28:29 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id 4CF29114A75;\n\tWed, 22 Apr 2026 18:28:21 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776875312; cv=none;\n b=G+rYosixMOqCFZQgkCcUE+9l8yJ2SbIOeYgO9XJYMIUgByHl2Woll/RJzpQFZbUqWuT35f5Qj7uwhR6/BStc1bMBX3pH4E0Pfxtk338MwbzR515fQ9kfHbVjkcxoxLCSb0+42kKNLR5zJSH0R+rI540PMTm+17PH99/0NzVjQxw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776875312; c=relaxed/simple;\n\tbh=qhlbZbIGVHQy9LrIzp3QdBPC1fyAcxZI52H9IQOGLT8=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=MDWt7fe3nRp2v4MKqogybAGklGHh9rLb7TwKrUrvXZQuBMF+CRVgT8Koc2JI0w/qj6CmjrgCnJ418/+DO/EzGSSElYCTVvOiUvhjoXelfY5vtwu6R4hiOWaGjNaOxrVfP+kakGxO/riXUzJ3tBz9AHtj6iEQKb18rYjEmKBf8Pk=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com;\n spf=pass smtp.mailfrom=nabladev.com;\n dkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=aIpE0Krw; arc=none smtp.client-ip=178.251.229.89","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nabladev.com;\n\ts=dkim; t=1776875301;\n\th=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t content-transfer-encoding:content-language:in-reply-to:references;\n\tbh=0nHk+0iP3Aq5bsqejM+w9/UT3yt1JZ6+Jx5bItZNCFo=;\n\tb=aIpE0Krwozdrzo8akDTgkbSL6tT3B278YiJ6oECuimrh4hGN6cudcc1yUsQol5jqm4yq40\n\tZwtSHkcS0KzGOWbZIRyS36Ymofe2uhVL2Ybi8TTDbIL+23SHu8jo9A76PPYiyWybcTMfIH\n\tmY4zR8Cvl+WZLE4NZpar+eR4ZY29polMi3ZbgDcbn0ekFO8OxcOiwrRqmE6t22m6Iq2HyN\n\tKnya7cpf69rM+f1xsZS9rBXoHQXJutvwpoMhWiqQDfqQizV8msX05RN1BY60ncRyXpv/0x\n\t0Z3CwjPzNP5+4WJ9obIuf62hv/gMruJAbBi0w6KEKJdiRKxrhJXbOsAumlibeA==","Message-ID":"<210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>","Date":"Wed, 22 Apr 2026 13:33:08 +0200","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","To":"Bartosz Golaszewski ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n Greg Kroah-Hartman ,\n Srinivas Kandagatla , linux-kernel@vger.kernel.org","References":"<20260421140755.54222-1-marex@nabladev.com>\n ","Content-Language":"en-US","From":"Marek Vasut ","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-Last-TLS-Session-Version":"TLSv1.3"}},{"id":3680719,"web_url":"http://patchwork.ozlabs.org/comment/3680719/","msgid":"<24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>","list_archive_url":null,"date":"2026-04-22T17:01:40","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":91452,"url":"http://patchwork.ozlabs.org/api/people/91452/","name":"Marek Vasut","email":"marex@nabladev.com"},"content":"On 4/22/26 1:33 PM, Marek Vasut wrote:\n> On 4/22/26 11:07 AM, Bartosz Golaszewski wrote:\n>> On Tue, Apr 21, 2026 at 4:08 PM Marek Vasut wrote:\n>>>\n>>> Handle special-case of AT24 EEPROM described in DT, which contains both\n>>> \"read-only\" and \"wp-gpios\" properties. Interpret this configuration as\n>>> default read-only, but with the possibility of unlock via force_ro sysfs\n>>> attribute.\n>>>\n>>\n>> Patch looks ok code-wise but does this really make sense? If an EEPROM\n>> is read-only, we should forbid writes in the kernel. Which board uses\n>> it? Can we simply remove the read-only flag from DT?\n> \n> Currently I am not aware of any upstream users, I plan to introduce one \n> once this patch or some for of it lands.\n\nI have to amend my statement, I would also like to adjust an already \nupstream DT to make use of this default-read-only functionality now.\n\nI would however like to get go/no-go on this patch before I roll out the \nDT patches.\n\n> I have is an ID EEPROM which I would like to be able to program under \n> special circumstances (hence the wp-gpios control) , but it should be by \n> default read-only .\n> \n> If I remove the read-only, then by default the EEPROM is read-write, \n> which is undesired. If I remote wp-gpios then I loose access to the \n> force_ro attribute which controls the nWP GPIO from userspace, which is \n> undesired.\n> \n> So I think defining this special-case where wp-gpios and read-only are \n> used together as default-read-only is sensible.\n> \n>> Admittedly: the DT bindings do allow it as read-only and wp-gpios are\n>> not mutually exclusive but I think it's more of an accidental omission\n>> than a planned feature.\n> I think it is currently an undefined behavior, and this patch defines it.\n\nAlso, this default-read-only behavior is effectively the same behavior \nlike the eMMC HW BOOT partitions have, they are also default read-only, \nbut can be switched and written to by setting their force_ro sysfs \nattribute.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=nabladev.com header.i=@nabladev.com header.a=rsa-sha256\n header.s=dkim header.b=ZKANe1kF;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17126-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=\"ZKANe1kF\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=178.251.229.89","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=nabladev.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g15Kh6wG6z1yCv\n\tfor ; Thu, 23 Apr 2026 03:08:56 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id D89D23033F81\n\tfor ; Wed, 22 Apr 2026 17:01:47 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 17409383C79;\n\tWed, 22 Apr 2026 17:01:47 +0000 (UTC)","from mx.nabladev.com (mx.nabladev.com [178.251.229.89])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 0679D17DE36;\n\tWed, 22 Apr 2026 17:01:44 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id 4982D114A8F;\n\tWed, 22 Apr 2026 19:01:41 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776877306; cv=none;\n b=ONkmLoUNwqb1XkdWkEV1u70wzk4zpM5VfF7DsIucHqNlODj3sCPPJMxgDCZlHzbna9BVsBVrJ38Oarz2JIXDt0BQHkqg04Ug+9ukXmsTw2gZ7gZh6HdzcAgAw6UzgM3G9v52JRGgHeYWh3PDA1w3IFOQLPHg583bsIYcvXKaIw0=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776877306; c=relaxed/simple;\n\tbh=zCAQyDnoDjTRLs97PQNQuco7Ndshntfn+BBJPKrSWtk=;\n\th=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References:\n\t In-Reply-To:Content-Type;\n b=Qj+Cmd+YWquTHjVMQevZvVRIK56jSsnA5Bu3YQxwoM4DAuLBMsQmr3BvlwKxIX4nNe/LNZn5iEkIHxh3j1VOSCfxiACiREk3QBwG625MZLPXgtfh3OlCT7xUUGHPK2UuD8E2u0vn1893li0OqQBtgFV4F6k0DVcLBFtheqRoQBs=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com;\n spf=pass smtp.mailfrom=nabladev.com;\n dkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=ZKANe1kF; arc=none smtp.client-ip=178.251.229.89","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nabladev.com;\n\ts=dkim; t=1776877302;\n\th=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t content-transfer-encoding:content-language:in-reply-to:references;\n\tbh=WIWMHVN1WP9qGUnpYBdTuFjk9vviDRD+CjgNIh5iSDc=;\n\tb=ZKANe1kFmtR8oJSL3SCaR2e/vYrqiitEF9+IwhwQSD+2Neql2PZ0uj9eEPA8nPdfkGfUYX\n\tV4AORktfsfMzFCtVDxEUoS/2OI9ZgjNXytbeUarzeCTEx1IZWvjlBX0Qn6hLPO1JVR/83x\n\tPG5q8hFRO0ZY9zIUiPmwORYTdRJUWIPKQ2IfQpzYAHDWBnbuGipoFZDC4W4YsEGuASUvrZ\n\tN4OlF+yxssJzub4mRDON0kB9HtEJ0Ln+G8oTB2kVb/p3K7uIcdah2IHBXWDLX9PjQIIoN3\n\tjB9OBALHRER60/XHzwvjqvE7jqGY4lrTYKEKrPOs5ncLIzJoUwTuACiNjMBFeQ==","Message-ID":"<24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>","Date":"Wed, 22 Apr 2026 19:01:40 +0200","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","From":"Marek Vasut ","To":"Bartosz Golaszewski ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n Greg Kroah-Hartman ,\n Srinivas Kandagatla , linux-kernel@vger.kernel.org","References":"<20260421140755.54222-1-marex@nabladev.com>\n \n <210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>","Content-Language":"en-US","In-Reply-To":"<210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-Last-TLS-Session-Version":"TLSv1.3"}},{"id":3681310,"web_url":"http://patchwork.ozlabs.org/comment/3681310/","msgid":"","list_archive_url":null,"date":"2026-04-23T07:42:54","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":92191,"url":"http://patchwork.ozlabs.org/api/people/92191/","name":"Bartosz Golaszewski","email":"brgl@kernel.org"},"content":"On Wed, Apr 22, 2026 at 7:01 PM Marek Vasut wrote:\n>\n> On 4/22/26 1:33 PM, Marek Vasut wrote:\n> > On 4/22/26 11:07 AM, Bartosz Golaszewski wrote:\n> >> On Tue, Apr 21, 2026 at 4:08 PM Marek Vasut wrote:\n> >>>\n> >>> Handle special-case of AT24 EEPROM described in DT, which contains both\n> >>> \"read-only\" and \"wp-gpios\" properties. Interpret this configuration as\n> >>> default read-only, but with the possibility of unlock via force_ro sysfs\n> >>> attribute.\n> >>>\n> >>\n> >> Patch looks ok code-wise but does this really make sense? If an EEPROM\n> >> is read-only, we should forbid writes in the kernel. Which board uses\n> >> it? Can we simply remove the read-only flag from DT?\n> >\n> > Currently I am not aware of any upstream users, I plan to introduce one\n> > once this patch or some for of it lands.\n>\n> I have to amend my statement, I would also like to adjust an already\n> upstream DT to make use of this default-read-only functionality now.\n>\n> I would however like to get go/no-go on this patch before I roll out the\n> DT patches.\n>\n\nYes, go ahead.\n\n> > I have is an ID EEPROM which I would like to be able to program under\n> > special circumstances (hence the wp-gpios control) , but it should be by\n> > default read-only .\n> >\n> > If I remove the read-only, then by default the EEPROM is read-write,\n> > which is undesired. If I remote wp-gpios then I loose access to the\n> > force_ro attribute which controls the nWP GPIO from userspace, which is\n> > undesired.\n> >\n> > So I think defining this special-case where wp-gpios and read-only are\n> > used together as default-read-only is sensible.\n> >\n> >> Admittedly: the DT bindings do allow it as read-only and wp-gpios are\n> >> not mutually exclusive but I think it's more of an accidental omission\n> >> than a planned feature.\n> > I think it is currently an undefined behavior, and this patch defines it.\n>\n> Also, this default-read-only behavior is effectively the same behavior\n> like the eMMC HW BOOT partitions have, they are also default read-only,\n> but can be switched and written to by setting their force_ro sysfs\n> attribute.\n\nI see. Ok, please send a v2.\n\nBart","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=gQgYL2Bi;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17139-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"gQgYL2Bi\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1SnZ0b8Gz1yD5\n\tfor ; Thu, 23 Apr 2026 17:45:54 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 13D193023CA2\n\tfor ; Thu, 23 Apr 2026 07:43:10 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 3E2D230B50C;\n\tThu, 23 Apr 2026 07:43:09 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id C2C1E311973\n\tfor ; Thu, 23 Apr 2026 07:43:08 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 4FF57C2BCB5\n\tfor ; Thu, 23 Apr 2026 07:43:08 +0000 (UTC)","by mail-lj1-f172.google.com with SMTP id\n 38308e7fff4ca-38e7d983f91so68100851fa.2\n for ; Thu, 23 Apr 2026 00:43:08 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776930188; cv=none;\n b=mnue3CuDEyJTIwSoZ8boZIZLR2B24cAWirjv1ODo88OHzkeOnq+i8cMrSlEVJy+yNpk8BOVv1cU7BB2YDZ27CCIQirFR9l3Vi1UlNsHn/d4OdF8gD4AnKgSB3X/unHpot+VXZeqOMgaut03WQGpvC2j7yZQltHvtv0M1Ukpi1kA=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776930188; c=relaxed/simple;\n\tbh=JtdGa6G+L1Cw57le4y0yN4OuqHi1KwvKyW3sw0H+4cw=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=It1zOl2Ln0iMbSeWLoIbZmB3aKho00jGeUBxjlJm2HhihVsuI9HIt68CKqmAGM0MsvZ2a4l+kgD5smFEJ2HIjtPzOCusOIEe34x3e7LkF2RjGhJ2vSW5pc5zk2moL33vGPfWIqFrkaq8ldAHclc1MOtK2BdWxcZ04Y93uzdFa2M=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=gQgYL2Bi; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1776930188;\n\tbh=JtdGa6G+L1Cw57le4y0yN4OuqHi1KwvKyW3sw0H+4cw=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=gQgYL2BiUBF718Lms5blGM2SAGCi/bsWzSDJPdIL9XX6pANwqzjxiz6Y8HR79fxJR\n\t bldWPgXSprR4GjrHtfa/mEmSE2Vy9yqvBOQjq0Qk5qIQ1g+S0sF3rMLD1wcBN1zBoD\n\t zu4+DmtY/uhuGj8qW1/SMpT1iOkEoMAJeQ18LH9XpV99HJ/HWxw4b/fnU63mxH9NbD\n\t uUHHcQQIyWoTTuS8Cu0CdpTPEJJcsFqhLMx7ATksgTlAvfQYZT4StCeulPt2jIhtk0\n\t HKHOPTsBeA2RZwXsWg4A20AmsvvLqN7StjvSodDBDSS7Mk+berlLjfGA2gmHqtZkKz\n\t HCw7zbiCWgieg==","X-Gm-Message-State":"AOJu0YxALk9bdSUDMcBcDHaFhwY+LP/glc0jznGaUH1G3R3II78lF/Lf\n\tZ39jK/Axnv5HSMbpQCbagZKCWZucoR3cq8SVHSrcJBn74tA0rCwQqRkcyUut4e3LLAbqQISIEDz\n\tESxEFRgO1faA7EYTwfsGmPb3ZVCwAsjWpHph5LrA8Nw==","X-Received":"by 2002:a05:651c:2109:b0:38e:8411:c300 with SMTP id\n 38308e7fff4ca-38ec7a987d7mr83176621fa.22.1776930186993; Thu, 23 Apr 2026\n 00:43:06 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260421140755.54222-1-marex@nabladev.com>\n \n <210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>\n <24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>","In-Reply-To":"<24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>","From":"Bartosz Golaszewski ","Date":"Thu, 23 Apr 2026 09:42:54 +0200","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzAztcXXoPIbc0LFI4Kz72zdmWoggm76GA-BeDUMh26hRUJkgH9p1g0b3Os","Message-ID":"\n ","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","To":"Marek Vasut ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n\tGreg Kroah-Hartman ,\n Srinivas Kandagatla ,\n\tlinux-kernel@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3681414,"web_url":"http://patchwork.ozlabs.org/comment/3681414/","msgid":"","list_archive_url":null,"date":"2026-04-23T09:37:18","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":91452,"url":"http://patchwork.ozlabs.org/api/people/91452/","name":"Marek Vasut","email":"marex@nabladev.com"},"content":"On 4/23/26 9:42 AM, Bartosz Golaszewski wrote:\n> On Wed, Apr 22, 2026 at 7:01 PM Marek Vasut wrote:\n>>\n>> On 4/22/26 1:33 PM, Marek Vasut wrote:\n>>> On 4/22/26 11:07 AM, Bartosz Golaszewski wrote:\n>>>> On Tue, Apr 21, 2026 at 4:08 PM Marek Vasut wrote:\n>>>>>\n>>>>> Handle special-case of AT24 EEPROM described in DT, which contains both\n>>>>> \"read-only\" and \"wp-gpios\" properties. Interpret this configuration as\n>>>>> default read-only, but with the possibility of unlock via force_ro sysfs\n>>>>> attribute.\n>>>>>\n>>>>\n>>>> Patch looks ok code-wise but does this really make sense? If an EEPROM\n>>>> is read-only, we should forbid writes in the kernel. Which board uses\n>>>> it? Can we simply remove the read-only flag from DT?\n>>>\n>>> Currently I am not aware of any upstream users, I plan to introduce one\n>>> once this patch or some for of it lands.\n>>\n>> I have to amend my statement, I would also like to adjust an already\n>> upstream DT to make use of this default-read-only functionality now.\n>>\n>> I would however like to get go/no-go on this patch before I roll out the\n>> DT patches.\n>>\n> \n> Yes, go ahead.\n> \n>>> I have is an ID EEPROM which I would like to be able to program under\n>>> special circumstances (hence the wp-gpios control) , but it should be by\n>>> default read-only .\n>>>\n>>> If I remove the read-only, then by default the EEPROM is read-write,\n>>> which is undesired. If I remote wp-gpios then I loose access to the\n>>> force_ro attribute which controls the nWP GPIO from userspace, which is\n>>> undesired.\n>>>\n>>> So I think defining this special-case where wp-gpios and read-only are\n>>> used together as default-read-only is sensible.\n>>>\n>>>> Admittedly: the DT bindings do allow it as read-only and wp-gpios are\n>>>> not mutually exclusive but I think it's more of an accidental omission\n>>>> than a planned feature.\n>>> I think it is currently an undefined behavior, and this patch defines it.\n>>\n>> Also, this default-read-only behavior is effectively the same behavior\n>> like the eMMC HW BOOT partitions have, they are also default read-only,\n>> but can be switched and written to by setting their force_ro sysfs\n>> attribute.\n> \n> I see. Ok, please send a v2.\nDoes this patch require any changes ?\n\nI will be sending the DT changes separately.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=nabladev.com header.i=@nabladev.com header.a=rsa-sha256\n header.s=dkim header.b=cZ2SbGHc;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17143-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=\"cZ2SbGHc\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=178.251.229.89","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=nabladev.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1ZZj6K0Zz1yCv\n\tfor ; Thu, 23 Apr 2026 22:06:53 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 15BA5302A7CC\n\tfor ; Thu, 23 Apr 2026 12:04:03 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id EFF523E92A6;\n\tThu, 23 Apr 2026 12:04:01 +0000 (UTC)","from mx.nabladev.com (mx.nabladev.com [178.251.229.89])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id D0BA23537D0;\n\tThu, 23 Apr 2026 12:03:59 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id CD7C8113ECE;\n\tThu, 23 Apr 2026 14:03:56 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776945841; cv=none;\n b=Xbqbvbw3Njd6dHF91umW7ArRb4FPx+u/aXFPdhDUIdOclmK8UqRbVh6XHb8HKgp27rJhv/RHvmhgOTiuqQ4Ux3NsSTKkUQZy+NBMwgHlhNM/LYVXMLm73vxeGleN/CZn91moJn5nQX66SxrE0arFO7Oq84CbuqRAQXubNuKwc2U=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776945841; c=relaxed/simple;\n\tbh=u2W8iYeL9ijnxYkPiCQmiJOQU2rd3YS+TxljZyL/BeQ=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=jM5DBs9wKFsgMIdKfTaWvla5CJY+nQEnMSZubNNBNDFBIGT7ZugBKpsbYU10PeWbnL2r60m09CEchGxSXVA6KhNzQmoeM3hHrhEHSoXCkGZ6125M7o+agATDQv52B8jVz2Ene1ORTR+iybjc6oEMqlKvJNdyNPkrN/fz0zctH50=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com;\n spf=pass smtp.mailfrom=nabladev.com;\n dkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=cZ2SbGHc; arc=none smtp.client-ip=178.251.229.89","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nabladev.com;\n\ts=dkim; t=1776945837;\n\th=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t content-transfer-encoding:content-language:in-reply-to:references;\n\tbh=fEYw6FuYgxS/qvu0/UHGRW7vNKtIjVSHDP0XY+qtk/k=;\n\tb=cZ2SbGHcWN8F0K2DHgP+jxVjDLVykwjtfAHbzNZo4KJV84VwwUxLB8hyYhLi3QmMMjQSeX\n\tDSsIgrM1rvLoLdEb/t+f+FaomOK1CRzNJiJqSAQfa5m8Ac+m1JhEO78JVic1/f4ocm7DF1\n\thvhqX7HVbAHLR7WSiINwTnKgZpm9MH0mt0AiTuNo5GzfmpteGYrq3g1REZtb3CM+jh5xNS\n\t1nNLSQuiGfpW2F0+V9Q5ONW5QJfMIn3gxrCFN9Z0RzbR+F3XGF7XtYMct+7XqFhaefuhA/\n\tNwL8mSq4sL87o+zFpH2Y6TyCDCCi/Lb/mM4nnuklS8aobHQNGTFqN0fewq6EpQ==","Message-ID":"","Date":"Thu, 23 Apr 2026 11:37:18 +0200","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","To":"Bartosz Golaszewski ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n Greg Kroah-Hartman ,\n Srinivas Kandagatla , linux-kernel@vger.kernel.org","References":"<20260421140755.54222-1-marex@nabladev.com>\n \n <210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>\n <24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>\n ","Content-Language":"en-US","From":"Marek Vasut ","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-Last-TLS-Session-Version":"TLSv1.3"}},{"id":3681421,"web_url":"http://patchwork.ozlabs.org/comment/3681421/","msgid":"","list_archive_url":null,"date":"2026-04-23T12:17:06","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":92191,"url":"http://patchwork.ozlabs.org/api/people/92191/","name":"Bartosz Golaszewski","email":"brgl@kernel.org"},"content":"On Thu, Apr 23, 2026 at 2:04 PM Marek Vasut wrote:\n>\n> >\n> > I see. Ok, please send a v2.\n> Does this patch require any changes ?\n>\n> I will be sending the DT changes separately.\n\nSashiko is saying this:\nhttps://sashiko.dev/#/patchset/20260421140755.54222-1-marex%40nabladev.com\n\nShouldn't we report the device as read-only in sysfs unless it was\n\"unlocked\" with force_ro?\n\nBart","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=OCIaw5WU;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17144-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"OCIaw5WU\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1ZzJ3Kgbz1yCv\n\tfor ; Thu, 23 Apr 2026 22:24:44 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 201583070ADA\n\tfor ; Thu, 23 Apr 2026 12:17:28 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id E2B793EC2E7;\n\tThu, 23 Apr 2026 12:17:27 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id E8A283DEAEB\n\tfor ; Thu, 23 Apr 2026 12:17:21 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 38B35C2BCB3\n\tfor ; Thu, 23 Apr 2026 12:17:21 +0000 (UTC)","by mail-dl1-f43.google.com with SMTP id\n a92af1059eb24-12c6df0b9bbso740191c88.1\n for ; Thu, 23 Apr 2026 05:17:21 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776946642; cv=none;\n b=sZDOwpTt4kUiMrN/S7T3LDFLJgDYo/RcsOYZepyPqMCQhqg4BYHcFAxfYnU3/m1v1HITh43oTOO7SVq1NvpUxpDW/tSw509dPI9chTAgam9GeEZPqwbM90uvxkPB07wsuhVK+zVjWFWQd1wmXR+sq7eblCaQMfL7bS3kNlaKxDU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776946642; c=relaxed/simple;\n\tbh=EGXTp0wx6AQ9wDHrDij1sKvhPUQTzuTtCxQwrDfCxn0=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=DR2f50ih92KlGW9v/7/WQhXBaO0ASQPuWVZ/qU0V8nNFVqUvwpCsrY7hf1tPfu4d5WqgeE2f6WI2mlDwXfHlVFE27RO8nZ7hh/wAq9bqww6xKE+XWj0K9STTjM/7fzKBDnMi3ygdPwIN+oRIUJqRLEpQoIZJP5uzU47VhmL/6yc=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=OCIaw5WU; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1776946641;\n\tbh=EGXTp0wx6AQ9wDHrDij1sKvhPUQTzuTtCxQwrDfCxn0=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=OCIaw5WUpGJ1CqRR7u/rSYZiK8JGwbEIdeksWC4jB+60HPkYkAyB7cm44bOw4qFt2\n\t fut41QpKI19D8AputEW4KKpAEduwr2hMvy4GQCYe/hWOmrzIajUPUTaij4eQimUIGo\n\t 9FXZRbF30PMLz9VVX6evvvLSmdKzx5HWOjsOD96rAXc0mOklTNDa2XXPvpqUKwf4SI\n\t r0rJIXDugMHiIPC4ZtTr6P/+RDmLduTB5kJV+j99qGWNOurFNxLg23Nh9NODQGbvho\n\t qCfgZpNtTrAwX9TSkYCMU3pNawQj0IobHVCcxKt+GR2RlwPR2eVW6sL2KCtpG8k7vg\n\t dwv2TItPczB4w==","X-Gm-Message-State":"AOJu0YwUYuXpxokjIXNClAXzR1/a/EI5A+6eZUDcdT6ayEgKlo+uiiTp\n\tDtfH/3SKZKYfU/HLV/ZwB4HdDfYJHxGiyBGLdUdr/qbXLUmKomlj2xQtMvUQnWXFjXApj4+rR9L\n\tXDVS28XIAoSrXYxBYF9p9mXk/46FObb19zn/76qFXyA==","X-Received":"by 2002:a05:7022:23a5:b0:128:d752:e076 with SMTP id\n a92af1059eb24-12c73f6c3dcmr15916280c88.3.1776946640543; Thu, 23 Apr 2026\n 05:17:20 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260421140755.54222-1-marex@nabladev.com>\n \n <210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>\n <24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>\n \n ","In-Reply-To":"","From":"Bartosz Golaszewski ","Date":"Thu, 23 Apr 2026 14:17:06 +0200","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzCO8Sm90soKwBuKVLc0aPo4U7aGgZVfn6g4O6wojs1Zmi3ad_KifJUZL4g","Message-ID":"\n ","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","To":"Marek Vasut ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n\tGreg Kroah-Hartman ,\n Srinivas Kandagatla ,\n\tlinux-kernel@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3681483,"web_url":"http://patchwork.ozlabs.org/comment/3681483/","msgid":"","list_archive_url":null,"date":"2026-04-23T14:06:36","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":91452,"url":"http://patchwork.ozlabs.org/api/people/91452/","name":"Marek Vasut","email":"marex@nabladev.com"},"content":"On 4/23/26 2:17 PM, Bartosz Golaszewski wrote:\n> On Thu, Apr 23, 2026 at 2:04 PM Marek Vasut wrote:\n>>\n>>>\n>>> I see. Ok, please send a v2.\n>> Does this patch require any changes ?\n>>\n>> I will be sending the DT changes separately.\n> \n> Sashiko is saying this:\n> https://sashiko.dev/#/patchset/20260421140755.54222-1-marex%40nabladev.com\n\nWhat does this mean ?\n\n> Shouldn't we report the device as read-only in sysfs unless it was\n> \"unlocked\" with force_ro?\nThis would be ideal, but I did not find a way to toggle the \"nvmem\" bin \nattr permissions at runtime. Is that even possible ?","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=nabladev.com header.i=@nabladev.com header.a=rsa-sha256\n header.s=dkim header.b=X7lYl2yI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17145-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=\"X7lYl2yI\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=178.251.229.89","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=nabladev.com"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1dFY3FGTz1y2d\n\tfor ; Fri, 24 Apr 2026 00:07:13 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 1E85B3001A58\n\tfor ; Thu, 23 Apr 2026 14:06:43 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id DEE1530FC1E;\n\tThu, 23 Apr 2026 14:06:41 +0000 (UTC)","from mx.nabladev.com (mx.nabladev.com [178.251.229.89])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id E76D02DC32C;\n\tThu, 23 Apr 2026 14:06:39 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id 3CF3811218E;\n\tThu, 23 Apr 2026 16:06:37 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776953201; cv=none;\n b=f2sA0MEcTNU+2WioXXpey6W3nl7fyqsAd9/gEMXzIgT67P4eEqNUgpZCp2P/zBQF0pu067G2ANu/BkbPybGbscemkPCXyCF3Z5ogUOtXZfciaFAPqAQzzYzTHv3qY0/o2gkdgb2aKoKQdPKvwC8bEx146JFNvPLoMcuG9MZrHyI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776953201; c=relaxed/simple;\n\tbh=Eqh5lBPKycPDN7GRwYNRKp2ahNPFkqvtOYc9wY9ETSI=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=fBtA07etEcLXrCmDXC3n2z2B5DDTzNz2eBZ0vOpMn0rb4PQJa1o1i+WfNlrHTsKSahWf26m3wLaUHm/po5BuWVYAcTIRhwnBbMHJEeLdc5JCRzPNQRY2lnmmAkwSmmdWLchw15iLjhJmk3KNsikmYfFe3mrJ3kTLgwq6tu8h1ko=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com;\n spf=pass smtp.mailfrom=nabladev.com;\n dkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=X7lYl2yI; arc=none smtp.client-ip=178.251.229.89","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nabladev.com;\n\ts=dkim; t=1776953197;\n\th=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t content-transfer-encoding:content-language:in-reply-to:references;\n\tbh=s3SefhIoL/isBNCFD1kBFH76UYZjae5zQ49OCSJALu8=;\n\tb=X7lYl2yITF/c8WFc2hBZUjkIUNDDv4gVxZTJ3xmVdwG+SFa2yCBK4hmIiEpDMgIvqGrZTv\n\tlfsTISmkDQevJd/cF7p/0qTYU+gzxdgwI+y9kDYXQmk/3EB53MrbI2V9FFb3Vkvv4a8lw8\n\tsu9dfzj7YKUdThuszoa55QPCdMWfNooFhKCITvGfEPTjcaMWwH3OgtfPhQXqsTt1WPkqwm\n\t/3H5WXt2qKPGvDlBoC9VSXNHknRRHf/VOuhR5q64CFuh0ibkCGnlc3vnsXO32TCiuBBId8\n\tvuyW0dMiaQC/qAgGPYab3r/OisDp5+NvFw8ZqzLQRiSukvrl34zhfs+5RhgmSQ==","Message-ID":"","Date":"Thu, 23 Apr 2026 16:06:36 +0200","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","To":"Bartosz Golaszewski ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n Greg Kroah-Hartman ,\n Srinivas Kandagatla , linux-kernel@vger.kernel.org","References":"<20260421140755.54222-1-marex@nabladev.com>\n \n <210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>\n <24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>\n \n \n ","Content-Language":"en-US","From":"Marek Vasut ","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-Last-TLS-Session-Version":"TLSv1.3"}},{"id":3681499,"web_url":"http://patchwork.ozlabs.org/comment/3681499/","msgid":"","list_archive_url":null,"date":"2026-04-23T14:19:47","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":92191,"url":"http://patchwork.ozlabs.org/api/people/92191/","name":"Bartosz Golaszewski","email":"brgl@kernel.org"},"content":"On Thu, Apr 23, 2026 at 4:06 PM Marek Vasut wrote:\n>\n> On 4/23/26 2:17 PM, Bartosz Golaszewski wrote:\n> > On Thu, Apr 23, 2026 at 2:04 PM Marek Vasut wrote:\n> >>\n> >>>\n> >>> I see. Ok, please send a v2.\n> >> Does this patch require any changes ?\n> >>\n> >> I will be sending the DT changes separately.\n> >\n> > Sashiko is saying this:\n> > https://sashiko.dev/#/patchset/20260421140755.54222-1-marex%40nabladev.com\n>\n> What does this mean ?\n>\n> > Shouldn't we report the device as read-only in sysfs unless it was\n> > \"unlocked\" with force_ro?\n> This would be ideal, but I did not find a way to toggle the \"nvmem\" bin\n> attr permissions at runtime. Is that even possible ?\n\nRight, it seems like it's set once and can't be changed (Greg: correct\nme if I'm wrong).\n\nOk, nevermind the comment then. Maybe just split the changes into\nnvmem and at24 changes and I can take both with an Ack from Srini.\n\nBart","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=NXuA5/li;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17146-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"NXuA5/li\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1djm007lz1yD5\n\tfor ; Fri, 24 Apr 2026 00:28:11 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 53E7130C0A7B\n\tfor ; Thu, 23 Apr 2026 14:20:04 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 349FE318EDA;\n\tThu, 23 Apr 2026 14:20:02 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id D063A199FB0\n\tfor ; Thu, 23 Apr 2026 14:20:01 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id A6873C2BCAF\n\tfor ; Thu, 23 Apr 2026 14:20:01 +0000 (UTC)","by mail-lj1-f182.google.com with SMTP id\n 38308e7fff4ca-38dd575bca3so69151391fa.1\n for ; Thu, 23 Apr 2026 07:20:01 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776954001; cv=none;\n b=ckZhhoeLz8VBJv/jMwIVlXX3D2XkALnIApd/etwX+zaMdtzrrDYO/JqCXwhfKc4uEmBs2NpQJIuweUifxuOPs+fIden8VxLAmIjbcAJygC7RqNwG9zgxNgEEczEvLroYiP9oy51+ihMSiAqHfw0bS9ZJbHjFxDJz3b+oYkGJcHA=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776954001; c=relaxed/simple;\n\tbh=127/yzVKNXCtnq2BuF2Pn+pom/R/B+8FKlTgC2Gvq9I=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=BH6LSgFd18s8GZiSQUOEP6oUXSzAuKGxYDWiptYHqHhesh1GTgWMi/zUCO04yXAIaiEbjHCK/7EhKa6yG8hvad0l9hvBKYA85BJs1zAh/WKKQlOOO41L6I/hPpWNudjlA9ea0TxwWSA+V78phSs9p54N1JDVB79Kn4nYnf8joSU=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=NXuA5/li; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1776954001;\n\tbh=127/yzVKNXCtnq2BuF2Pn+pom/R/B+8FKlTgC2Gvq9I=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=NXuA5/li70xOFPXVxp3ccW3OTmGMcWHrXJQRUFFvHWnsEN/2KThxt/xtmu3X/F95n\n\t VXEDZC8UpFnrVBeT/ZvHnJ9SQkpEvMfUSUgjb3nzGlOO8/zqa3JlICcxd33iDJT/V8\n\t chZXyr/Bc3X8M1/nGAOiKEV9b+ynLHVzhKZO007s7RAn04KNvg5Xlpvrgxi5neS3lh\n\t csxeM9oVwu+x/DtBz+/+hP937MONphXGsKjd0w4mPauJ+bAKfCwcHncTAIkD0rjEf2\n\t DUwQR2XqVh0uc92dxLnA9d3CgDS8Jk/KjtP/C+qhYRdK+/a7//gKNI+19Y2wmv6Njs\n\t kNXurdfk8XcUA==","X-Gm-Message-State":"AOJu0YxEMPJ79oIGOcqdEm9F7x3qKwB93gJeMBRH8A619wVyy2dfA5yp\n\tHe66pzyNXBLytrsZ7J76tUri8j4QSd1Q/yopLGUaWj68SIfDlTx+zXk2JqREoipUZbJh8+sk1u3\n\t1wYX6oiUd6e4VrJaMNmfRhQ7JFHaCVffuOWn9hu+hFg==","X-Received":"by 2002:a2e:8e6f:0:b0:389:e6e4:3c7d with SMTP id\n 38308e7fff4ca-38ec94ea792mr56535301fa.19.1776954000301; Thu, 23 Apr 2026\n 07:20:00 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260421140755.54222-1-marex@nabladev.com>\n \n <210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>\n <24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>\n \n \n \n ","In-Reply-To":"","From":"Bartosz Golaszewski ","Date":"Thu, 23 Apr 2026 16:19:47 +0200","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzCd7b_9anTl417LIe4Egvhh_pku8YUqMZXh7cB6JofXb25scTjBEEDgsnE","Message-ID":"\n ","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","To":"Marek Vasut ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n\tGreg Kroah-Hartman ,\n Srinivas Kandagatla ,\n\tlinux-kernel@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3681645,"web_url":"http://patchwork.ozlabs.org/comment/3681645/","msgid":"<4a6c6822-28e1-4838-9262-f7b758f92736@nabladev.com>","list_archive_url":null,"date":"2026-04-23T19:15:37","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":91452,"url":"http://patchwork.ozlabs.org/api/people/91452/","name":"Marek Vasut","email":"marex@nabladev.com"},"content":"On 4/23/26 4:19 PM, Bartosz Golaszewski wrote:\n> On Thu, Apr 23, 2026 at 4:06 PM Marek Vasut wrote:\n>>\n>> On 4/23/26 2:17 PM, Bartosz Golaszewski wrote:\n>>> On Thu, Apr 23, 2026 at 2:04 PM Marek Vasut wrote:\n>>>>\n>>>>>\n>>>>> I see. Ok, please send a v2.\n>>>> Does this patch require any changes ?\n>>>>\n>>>> I will be sending the DT changes separately.\n>>>\n>>> Sashiko is saying this:\n>>> https://sashiko.dev/#/patchset/20260421140755.54222-1-marex%40nabladev.com\n>>\n>> What does this mean ?\n>>\n>>> Shouldn't we report the device as read-only in sysfs unless it was\n>>> \"unlocked\" with force_ro?\n>> This would be ideal, but I did not find a way to toggle the \"nvmem\" bin\n>> attr permissions at runtime. Is that even possible ?\n> \n> Right, it seems like it's set once and can't be changed (Greg: correct\n> me if I'm wrong).\n> \n> Ok, nevermind the comment then. Maybe just split the changes into\n> nvmem and at24 changes and I can take both with an Ack from Srini.\nI have two more ideas I would like to run past you ... how about either:\n\n- If wp-gpios is present, set the device as default RO after boot, and\n let force_ro sysfs attribute toggle the protection of the device back\n and forth afterward. This would however change the userspace facing\n behavior slightly, because right now, with wp-gpios present in DT, the\n device is default RW.\n\n- Introduce new DT property, wp-gpios-default-read-only or\n default-read-only or some such, to indicate the device should be in\n read-only mode by default. That would mitigate the downside of the\n aforementioned point, but would require a new DT property.\n\nThoughts ?","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=nabladev.com header.i=@nabladev.com header.a=rsa-sha256\n header.s=dkim header.b=QRcokavF;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17153-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=\"QRcokavF\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=178.251.229.89","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=nabladev.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1mBd18ckz1yCv\n\tfor ; Fri, 24 Apr 2026 05:20:09 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 5849330819BB\n\tfor ; Thu, 23 Apr 2026 19:15:53 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id C681738F925;\n\tThu, 23 Apr 2026 19:15:49 +0000 (UTC)","from mx.nabladev.com (mx.nabladev.com [178.251.229.89])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 9413628AAEB;\n\tThu, 23 Apr 2026 19:15:47 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id 530021133AA;\n\tThu, 23 Apr 2026 21:15:38 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776971749; cv=none;\n b=ghFVVjs8MnhblLb8eASrJo9NcxSCt4pB+ND0chNCzWmVy79oSqnNfb+/P/X1LTO6sD8vzlvlvLDF5v846Rf0HSgBfmFoN48ffU/fbsvwkRIDaVgToBbG6hU1NXyJpvRtN5cFcJulq629YOJzE/uS0VtjfJ6dZjhO7duj4VJQEek=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776971749; c=relaxed/simple;\n\tbh=qiwwxf9yhhHO8ZYoPylORcn7HC3ao+V5tI/uFOshm3w=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=edQ7OSS33/graSiaEEm/13sK2UznRM8iG3+/UgO1bq/OHpfaMl5Z9n9fRNt7NSpfsXmNnbO8/gyF6jbscgMxnqE9rjiXMDQYNX7hAzU16FDjNGbGeKNyPogudvnjcXgJyXOsv67CYpStkVT1TJie7RyDQK+WYn4hD3c5t40SVMc=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=nabladev.com;\n spf=pass smtp.mailfrom=nabladev.com;\n dkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com\n header.b=QRcokavF; arc=none smtp.client-ip=178.251.229.89","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nabladev.com;\n\ts=dkim; t=1776971739;\n\th=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t content-transfer-encoding:content-language:in-reply-to:references;\n\tbh=TJ2rCpjIbZOghBXli83/mp337qVhjpWNhUQPZsMkTLE=;\n\tb=QRcokavFUoi8C+quE6NbPZSe6Kutf4xWvZrBq2/o21IQbk0ogjcPUb5eR+7sGRiAkt0iDb\n\tr5Cpr/npGQYGhOaU7Aief2dwSQhmbJJE3Xhwm9rT77T/JeTrd5XhRJWBShUguCnQbo+g0P\n\t8lhfYIXVWtWxld0OzFbZgqvNxNDFQzhmBZd6akHhA0ElxVZu2x2DPCz62ymET+GLQl1sxp\n\tKYaowsnAQ0lNFs0mu5n796R90iMoY5wpGu5tEe4NqsN/XKGJ9kBXkNkXkVRINprYoLdug3\n\tZqyP4D6QCjP2BW5aqghuLeBuJ/NgzfxMXNiSP4dsS56Uht9cH4gGz0dYNd1Lgg==","Message-ID":"<4a6c6822-28e1-4838-9262-f7b758f92736@nabladev.com>","Date":"Thu, 23 Apr 2026 21:15:37 +0200","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","To":"Bartosz Golaszewski ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n Greg Kroah-Hartman ,\n Srinivas Kandagatla , linux-kernel@vger.kernel.org","References":"<20260421140755.54222-1-marex@nabladev.com>\n \n <210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>\n <24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>\n \n \n \n \n ","Content-Language":"en-US","From":"Marek Vasut ","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-Last-TLS-Session-Version":"TLSv1.3"}},{"id":3681856,"web_url":"http://patchwork.ozlabs.org/comment/3681856/","msgid":"","list_archive_url":null,"date":"2026-04-24T08:12:22","subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","submitter":{"id":92191,"url":"http://patchwork.ozlabs.org/api/people/92191/","name":"Bartosz Golaszewski","email":"brgl@kernel.org"},"content":"On Thu, Apr 23, 2026 at 9:15 PM Marek Vasut wrote:\n>\n> On 4/23/26 4:19 PM, Bartosz Golaszewski wrote:\n> > On Thu, Apr 23, 2026 at 4:06 PM Marek Vasut wrote:\n> >>\n> >> On 4/23/26 2:17 PM, Bartosz Golaszewski wrote:\n> >>> On Thu, Apr 23, 2026 at 2:04 PM Marek Vasut wrote:\n> >>>>\n> >>>>>\n> >>>>> I see. Ok, please send a v2.\n> >>>> Does this patch require any changes ?\n> >>>>\n> >>>> I will be sending the DT changes separately.\n> >>>\n> >>> Sashiko is saying this:\n> >>> https://sashiko.dev/#/patchset/20260421140755.54222-1-marex%40nabladev.com\n> >>\n> >> What does this mean ?\n> >>\n> >>> Shouldn't we report the device as read-only in sysfs unless it was\n> >>> \"unlocked\" with force_ro?\n> >> This would be ideal, but I did not find a way to toggle the \"nvmem\" bin\n> >> attr permissions at runtime. Is that even possible ?\n> >\n> > Right, it seems like it's set once and can't be changed (Greg: correct\n> > me if I'm wrong).\n> >\n> > Ok, nevermind the comment then. Maybe just split the changes into\n> > nvmem and at24 changes and I can take both with an Ack from Srini.\n> I have two more ideas I would like to run past you ... how about either:\n>\n> - If wp-gpios is present, set the device as default RO after boot, and\n\nIsn't this already what happens though? nvmem core requests the GPIO\nas output-high and drives it low only when it's doing the writing.\n\n> let force_ro sysfs attribute toggle the protection of the device back\n> and forth afterward. This would however change the userspace facing\n> behavior slightly, because right now, with wp-gpios present in DT, the\n> device is default RW.\n>\n\nOr do you mean just the file permissions?\n\nIf the latter, then that does sound logically sound but yeah, it's\nasking for a regression report. :)\n\n> - Introduce new DT property, wp-gpios-default-read-only or\n> default-read-only or some such, to indicate the device should be in\n> read-only mode by default. That would mitigate the downside of the\n> aforementioned point, but would require a new DT property.\n>\n> Thoughts ?\n\nI like \"default-read-only\" and it both allows to introduce this\nbehavior and not break existing users. Let's loop in DT maintainers\nand see. I'd just like to clarify if we're talking about sysfs\npermissions or GPIO behavior here.\n\nBart","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=rx6PST2W;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17157-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"rx6PST2W\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g25Ml4mn7z1xvV\n\tfor ; Fri, 24 Apr 2026 18:14:11 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 017773010503\n\tfor ; Fri, 24 Apr 2026 08:12:36 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 2DB9F3815C3;\n\tFri, 24 Apr 2026 08:12:36 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id C952F22256F\n\tfor ; Fri, 24 Apr 2026 08:12:35 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 74E5DC2BCB4\n\tfor ; Fri, 24 Apr 2026 08:12:35 +0000 (UTC)","by mail-lj1-f169.google.com with SMTP id\n 38308e7fff4ca-38e7d983f91so80179501fa.2\n for ; Fri, 24 Apr 2026 01:12:35 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777018355; cv=none;\n b=H3XmMncCIHBcOU3lG6tfK0XaAzRIYdraub90pbaxFqcK9kiDorSZaXinH290AjAmWphM6UONanuB7sCi0nGkyFO0kvxdrudgIkSK2JRnWP/HWWCL/yngCt+EYvNO4xs5EFcz+/azH5sCO3hXY4zg0SBmEDbRu78LjQmrs+A6u1c=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777018355; c=relaxed/simple;\n\tbh=2dpDTfL+kVbHUNaQeGHXGiDLbTwBsCQs6TRYjfHOQH4=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=ki6b2B++BpfkszGYlLTgEnobFRBvA1RWl1SADXm0bzZUMg68dsZbqEWVmqtUYbgHryFSMDPKG09zCVtbm2jEhNizoU3rRTeq+9kaUkcFpo0O0P1znMTja75qCIpb/fW2SEVlHKYbJET1Eo2iuiKQxaxZBaJfM0uZot0eQBdzNTs=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=rx6PST2W; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777018355;\n\tbh=2dpDTfL+kVbHUNaQeGHXGiDLbTwBsCQs6TRYjfHOQH4=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=rx6PST2Wu1CRMU83jUbpAHG1yLdcAOOiTr/p2D7StG0rVqbQIpNeWMeZo0ofsq3bf\n\t ++XhcmTWz3y0/FVXXtP9i2XkONs+VYosfB02lIaKXvcbcWOheLRU5CwnDTRUxwdez3\n\t VdTkLzthK51kYUP4clAc3fNh5EubpALUVRt8qhddEo0JI/nAldLg3oTZEq8PNyPak6\n\t 0YOZxBakA2b8Sho33YhOO8qcuUctOJ8Y+MfKIkRzZf8KRZ7LMDFbRsDziTUNR8PJKp\n\t HTVfPjMNBUnWdtA4Sc9KlYmtMbtURIBV4EWxqWnQDI2ty9cn1JskzwMrvKeyBn8QXy\n\t OicOgagPGelnA==","X-Gm-Message-State":"AOJu0Yys3sPLe4lV94lp1y2Rt9f4zjajo3AjrB8ztdOog3jLfmDFpCdA\n\tlYhhS2ledL1GEzjO2jxm2WMQCfhQNwIRiFIBWQLNjw2ma34MVGR0oFFZeZeBWubXbvPoJCxHP9D\n\tqPqmWe4RU4jrl2axshwWZ13nNspFnQ+/Mt7r5OHpROQ==","X-Received":"by 2002:a2e:bc27:0:b0:38e:9566:a309 with SMTP id\n 38308e7fff4ca-38ec7ac7625mr97898741fa.28.1777018354093; Fri, 24 Apr 2026\n 01:12:34 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260421140755.54222-1-marex@nabladev.com>\n \n <210b41ca-28be-42ca-819b-de5f17dddec7@nabladev.com>\n <24649001-4d21-4ddf-a171-842b0e7782e4@nabladev.com>\n \n \n \n \n \n <4a6c6822-28e1-4838-9262-f7b758f92736@nabladev.com>","In-Reply-To":"<4a6c6822-28e1-4838-9262-f7b758f92736@nabladev.com>","From":"Bartosz Golaszewski ","Date":"Fri, 24 Apr 2026 10:12:22 +0200","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzAG-xAt8AEYFGjNvp6vhvTiAxquIjQSJZgzmzuphSjEvPrhT7GNNjEaJHk","Message-ID":"\n ","Subject":"Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both\n read-only and wp-gpios","To":"Marek Vasut , Rob Herring ,\n\tKrzysztof Kozlowski , Conor Dooley ","Cc":"linux-i2c@vger.kernel.org, Arnd Bergmann ,\n\tGreg Kroah-Hartman ,\n Srinivas Kandagatla ,\n\tlinux-kernel@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}}]