Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Secumail-id: <213b.65099641.a2b8f.0>
Message-ID: <da400d3e-a357-1ae8-cb92-728cc4974b67@kalrayinc.com>
Date:   Tue, 19 Sep 2023 14:38:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH v2] i2c: designware: Fix corrupted memory seen in the
 ISR
To:     Wolfram Sang <wsa@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Jan Bottorff <janb@os.amperecomputing.com>,
        Serge Semin <fancer.lancer@gmail.com>,
        Yann Sionneau <yann@sionneau.net>,
        Will Deacon <will@kernel.org>,
        Jarkko Nikula <jarkko.nikula@linux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Jan Dabros <jsd@semihalf.com>,
        Andi Shyti <andi.shyti@kernel.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230913232938.420423-1-janb@os.amperecomputing.com>
 <i6h72feyrvo6pajo67b346masyxt7ycpfj46mvrfp4o7suh4ud@xuv5lu64s75m>
 <a7a85428-d40d-4adb-8f84-75e1dabe19c9@os.amperecomputing.com>
 <xxnggfauhkfum63p5bkgxsu3m5odyjda7pnwpb5ocwf4gez7fh@4lu6qyqy6dvh>
 <37e10c3d-b5ab-75ec-3c96-76e15eb9bef8@sionneau.net>
 <v4hdblxwhl6ncdfxre5gyrve7bgdsorfqpqj53ib6q4tr7aguy@4kfr6ergb3jn>
 <9de89e14-35bd-415d-97f1-4b6db1258997@os.amperecomputing.com>
 <ZQlwC9TCSwWJpuxy@arm.com> <ZQl1zwVkx9n2MPvr@shikoro>
Content-Language: en-us
From:   Yann Sionneau <ysionneau@kalrayinc.com>
In-Reply-To: <ZQl1zwVkx9n2MPvr@shikoro>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: iFKU3b8a2Na4X3LLw0PbAE6aaF8ynYEELNp9HYCZt4YZ5sMZ/w/gTDBwr7YoR4/11wqpC0rX61rGpwepcQ5YSAf0K4MAhm4tS01Y09HSrHhiHLLMFiClBkcD5o8hbzFiPhHdJ7EDZCKbzO7/QEFs22AqhDvOw8CrynUmAYuo3n7Lsf9nPGLFqViytSKCJ5wXysNHvq4W+He6DoC9AQXDBg/Qr4YclTlP+V6lbfZ7zuccvWXCOfVgV0Au3pMCalECpHYOuOqYHUPsIA6sldSlkevXpACyCXl9oconKT9hx3sJtps1UQzTi6c8+4nkxAoWr9iEqNiAsrYRB60LVjYrIlnQ4/OSI1V8Ri+rOy+Th4xmd+HTClGT7hud7QunWco+0PIhhGtYEWgHtGdVwJDhNTYBDRD/RP6AaAkAhIBqwDSd3sZ5bMQrbAhsCxBmwYhT5tgqbRQf0loylnqljP8pp7ko/LybXiQuG/rEMOXyRsK/Asb5+OTuUYUAbBxWd28VME/KDnCfFpJNpgiXIs0sYOiGj3Wo0vtNzWYrS+3fTyUf5ubkLygJBjb52xjjD0PyJGIs8aVcyBCoB11R/tT7U6imnskMpFj3gn0f1wJ+uHVPP1TQ6OYuYTrUaYGj48rtdNl6Tj+6z/MBjWnH4bLbyN5XdLkQzQhbkyp53f2uOPgzIptt/rWzcC8i7b2/dDHMLvy2bdwH5NcM5vn6Bq1/11UZ0Ok8GdmGbiHHH2GBCUQq9Iif9LhDjvBbxOLRumUMthrG3CJuM6dBXMuCYl73cRjMu6nISX+CJijUrA7p5oHYbMTQmto19jtIgQMhhNbYMXMzm4nLVA5uPpOarX8tDCY1Wa4V9bQA+joXsDffaEyG+5qv4ocdtUaXUTTzCefSQpaUZrfz0GbPMRNvA5SCNhWFsStAVMFC0+vsZ4vWGJXq0r+5C2XlDnLO3NPwtdLq
 425B63N5wUjAi7qDPSB17MEQuexpaueb1i/NBpyIwyfwTpARrzpGhnL3DCDpe9KY0WnD0pFkNscFJoGhe0XKc0E1IMyITQnoF8gU4aN7vv9cODO0xvq0l4f29a9uHt/v5pLcd3KuZf4L/l2DzRmDggU2BbJwDaO2p78JQ5YIsYKIuEw4pJwpWPueZ0XdoxKKejY9aM0BD54FUHlK8w7t+tmFAoE/2VEk7tuLnI9UOrEijxMEHLTKne3iNX+6mejJBqkmg2FFeFn2s998jH2W/kC3weQ7sg0lchv3PCVjgYOGPIfQ8e46i2d13po+NyTCtBFlyDCv77+P3n1InVGWVnqj+K9eYV6UIVqlb8d+L5nBbtxBahgbD+67aMMZVft1VR9vrlypgtWjQdD4R7rsu0B/3atHCTJ1JaQh47SXHMt9+myGVh3DOlBOgORYFvZO8shjvNYxiR7iFMwEl0eQDzqjhg7Xqt9XsEWT2Htitp1aF46WIilvENAFpTNDPG/omnS+iik5ceGbrQoKfczex2NPbON4eBdrubTqKgWn1NFeVReaO2A0GeY5/wcuWqJDJBqaydaAJYLkQj/eTuF6wcJ6nM/o7hHNCg0XAnu80O+C/c3rrJBTIiXQ9cZRed05ovDf95vYi0M/BVMOw5i2qw==
X-OriginatorOrg: kalrayinc.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 475df8a4-3006-44d5-5953-08dbb90d505a
X-MS-Exchange-CrossTenant-AuthSource: MR1P264MB1890.FRAP264.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2023 12:38:23.9698
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8931925d-7620-4a64-b7fe-20afd86363d3
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: JJCZXzmrLc3wNd93961QIA+ZiVGZkA2g9cTkWStlodWaXhKQ7aZ4dXVsR248bit70bW62++q8sfJz1cUh+bn7A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1P264MB1567
X-ALTERMIMEV2_out: done
X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,T_SPF_TEMPERROR autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 19 Sep 2023 05:38:49 -0700 (PDT)

Hi,

On 9/19/23 12:19, Wolfram Sang wrote:
>> I also agree that a wmb() in the i2c driver is not the more elegant fix.
>> For similar reasons, we hid barriers in the write*() macros, drivers
>> need to stay architecture-agnostic as much as possible.
> Exactly my thinking. I wanted to read this patch discussion later this
> week. But from glimpsing at it so far, I already wondered why there
> isn't a memory barrier in the final accessor to the register.

The regmap accessors used by the designware driver end up calling 
writel_relaxed() and readl_relaxed() : 
https://elixir.bootlin.com/linux/v6.6-rc2/source/drivers/i2c/busses/i2c-designware-common.c#L71

Those usually end up just being volatile accesses, making some kind of 
compiler barrier preventing the memory mapped register accesses to be 
moved/removed/merged.

I kind of think it's OK. It starts not being OK when you want some 
ordering between those and some memory accesses in DDR like the problem 
discussed here.

In those cases I would say the smp_* barriers are what we are supposed 
to use, isn't it?

Regards,

-- 

Yann