Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp99346imm; Thu, 12 Jul 2018 15:02:08 -0700 (PDT) X-Google-Smtp-Source: AAOMgpclaBmDFwEhSb7JYxkPBOXDSZYV3dOZNdR0PSdNddMk+DEzmTJOhIKu2W4W9VQgDfPqQpJv X-Received: by 2002:a62:6303:: with SMTP id x3-v6mr4180102pfb.91.1531432927910; Thu, 12 Jul 2018 15:02:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531432927; cv=none; d=google.com; s=arc-20160816; b=i5gWKayc3z96D996C07vWLA7T7uP7OH1nVlyYu8osT6cdSS5SBR6zWiwn+qZ24AC6q 4pOnUXE61uBEMIdxDNFGhXyX+8jxKpFPg5sK6hrpe7g+dJn1s90ZlMIT5qDeaJqkNf1V gnSXlUxr4teEkRTwzH6aig5S1VVkrzT1QjpJ64R49ChkWio6OqZkCz3iS0EjFLHzv+9h gJHCf+vx6T2E6MFSeNTjHy9ik9ln9nAvcxwO6nPLEVfzVeEh7YhYWwZZvN5VsGb/jG/u J5NrzMLD4oJ2BCkJQBAnp971r0OirMaFYTZvAzXZwSop3goQKSte6Iz2KNYaeTNLSmAU +Z4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=13BzDJZdBVROU81AU4mCNZcH19rhSHagC7cl7Gpy7cU=; b=UAEoEdV+hyX0JgAJ702RV6yrxADoq15nTYw6OKQG/m8b9P+mKos1RfNTA6Yzj95O/6 Qlo2GVKiZ079CpNzJTHa6fiSD+YhlIKgiOnUU0g4BxirHAFZ/DOh83AGd1NQL6LCM0TJ oSQmN9Vm0un3MeRPv+GETZ2ucMg9ld3O1XBlJ3EOYg2YTinjGaHhfdKxo+H6FLuM+h4l da0KOlD5x9VUoT9QaP91V9jag1Zm51ulckXL9nNqUIlqqD66nfOcY/QjzqEmmM866wCK oDFu8WiQgDCxLspBAgU1r+mHk891lTSWpdKN3RiMNg4fkWqh11HDpPZErDxQVjG04Hi1 q85A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b="g7/YUo+j"; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e20-v6si25150843pfm.177.2018.07.12.15.01.29; Thu, 12 Jul 2018 15:02:07 -0700 (PDT) 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=fail header.i=@infradead.org header.s=bombadil.20170209 header.b="g7/YUo+j"; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732448AbeGLWLb (ORCPT + 99 others); Thu, 12 Jul 2018 18:11:31 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:55414 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726919AbeGLWLb (ORCPT ); Thu, 12 Jul 2018 18:11:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=13BzDJZdBVROU81AU4mCNZcH19rhSHagC7cl7Gpy7cU=; b=g7/YUo+j0mKYAP8KH9qbKs2an Q5VKOMvd/25O+efN1/uerFXgeRuwgVfw4ivntPZYXMTGFm1c5fnHmKfNkAqr4bUEoDa2iticDT/E0 ya5qPF0Yvhy9aEp+X4p2aePs4mQfDl1h88QMfiL9wy5C44k4m0M7qpzli22374EAJSrn1Oel+/sCq Nkqp3tN9IXvvEggP5xGsC0Gcv7nA+qzXBMOVYXq6DrQst+3/8DAvlUFeaA5FGqtxbMD6Ph+lVkeWV aiHQ3a9Hh1y2nDq7NsoCwku32LDzUSQ2U5dRcaJH8WpGJ4Ww5iZ4TcWTJQ99HR1vUd7IXXmn8xMGp WTHzzbvNA==; Received: from 177.157.125.74.dynamic.adsl.gvt.net.br ([177.157.125.74] helo=coco.lan) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fdjcw-0000bl-2b; Thu, 12 Jul 2018 21:59:54 +0000 Date: Thu, 12 Jul 2018 18:59:44 -0300 From: Mauro Carvalho Chehab To: Wolfram Sang Cc: Peter Rosin , linux-kernel@vger.kernel.org, Peter Huewe , Jarkko Sakkinen , Jason Gunthorpe , Arnd Bergmann , Greg Kroah-Hartman , Brian Norris , Gregory Fong , Florian Fainelli , bcm-kernel-feedback-list@broadcom.com, Sekhar Nori , Kevin Hilman , Haavard Skinnemoen , Kukjin Kim , Krzysztof Kozlowski , Orson Zhai , Baolin Wang , Chunyan Zhang , Guenter Roeck , Crt Mori , Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Dmitry Torokhov , Antti Palosaari , Mauro Carvalho Chehab , Michael Krufky , Lee Jones , linux-integrity@vger.kernel.org, linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-iio@vger.kernel.org, linux-input@vger.kernel.org, linux-media@vger.kernel.org Subject: Re: [PATCH v2 00/10] Split i2c_lock_adapter into i2c_lock_root and i2c_lock_segment Message-ID: <20180712185944.62219cf6@coco.lan> In-Reply-To: <20180712212850.axi3rrfwivqymqh5@ninjato> References: <20180620051803.12206-1-peda@axentia.se> <20180626023735.xj7aqhvw7ta2lq6s@ninjato> <20180712212850.axi3rrfwivqymqh5@ninjato> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Thu, 12 Jul 2018 23:28:51 +0200 Wolfram Sang escreveu: > On Tue, Jun 26, 2018 at 11:37:36AM +0900, Wolfram Sang wrote: > > On Wed, Jun 20, 2018 at 07:17:53AM +0200, Peter Rosin wrote: > > > Hi! > > > > > > With the introduction of mux-locked I2C muxes, the concept of > > > locking only a segment of the I2C adapter tree was added. At the > > > time, I did not want to cause a lot of extra churn, so left most > > > users of i2c_lock_adapter alone and apparently didn't think enough > > > about it; they simply continued to lock the whole adapter tree. > > > However, i2c_lock_adapter is in fact wrong for almost every caller > > > (there is naturally an exception) that is itself not a driver for > > > a root adapter. What normal drivers generally want is to only > > > lock the segment of the adapter tree that their device sits on. > > > > > > In fact, if a device sits behind a mux-locked I2C mux, and its > > > driver calls i2c_lock_adapter followed by an unlocked I2C transfer, > > > things will deadlock (since even a mux-locked I2C adapter will lock > > > its parent at some point). If the device is not sitting behind a > > > mux-locked I2C mux (i.e. either directly on the root adapter or > > > behind a (chain of) parent-locked I2C muxes) the root/segment > > > distinction is of no consequence; the root adapter is locked either > > > way. > > > > > > Mux-locked I2C muxes are probably not that common, and putting any > > > of the affected devices behind one is probably even rarer, which > > > is why we have not seen any deadlocks. At least not that I know > > > of... > > > > > > Since silently changing the semantics of i2c_lock_adapter might > > > be quite a surprise, especially for out-of-tree users, this series > > > instead removes the function and forces all users to explicitly > > > name I2C_LOCK_SEGMENT or I2C_LOCK_ROOT_ADAPTER in a call to > > > i2c_lock_bus, as suggested by Wolfram. Yes, users will be a teensy > > > bit more wordy, but open-coding I2C locking from random drivers > > > should be avoided, so it's perhaps a good thing if it doesn't look > > > too neat? > > > > > > I suggest that Wolfram takes this series through the I2C tree and > > > creates an immutable branch for the other subsystems. The series > > > is based on v4.18-r1. > > > > Applied to a seperate branch named "i2c/precise-locking-names" which I > > will merge into for-next, so it will get proper testing already. Once we > > get the missing acks from media, MFD, and IIO maintainers, I will merge > > it into for-4.19. > > Ping for media related acks. For the media-related ones: Acked-by: Mauro Carvalho Chehab > > Thanks, > > Wolfram > Thanks, Mauro