Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4590717imm; Mon, 25 Jun 2018 19:38:56 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKsK1zhE2Zp2O+n3k+KTUc6HiFmwQ0R5uyZCAVCxRy6GBeo57nSXaKNgyaMmOuhwI26+Bei X-Received: by 2002:a17:902:bf43:: with SMTP id u3-v6mr14761146pls.322.1529980736543; Mon, 25 Jun 2018 19:38:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529980736; cv=none; d=google.com; s=arc-20160816; b=OXcX6LIBJmRJkvG39PFIYDqiYlcPSZs7fZoih335gZJWjAN8rwHesxb6fkAomYZV/w QEwVebIb93vBTYh++AswyyvjZjV4i5mJb5Y9drWRSqlx2+F95K5JKVyUQlSeSSEqCC9D XxSlvikzfL/b4ru6x0K9JT/uvd09GyvEIj7DcpALKAqNBLFD8QEPZQmmywylN1DCdlHW KGhLTOua6iSr4qH1kqB2w66qXDjtBDoMcfJ4I3gdVcHO47/90NxnqjLhMFWzVxkTe3Oh U/U3/93rLrPtpEgmxTTKVSXBOKoL+1g1vMFsTvqDI3HHFRO8Xs1xfZIbN2s/HFXQgBey kjRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=9k0uuh4euiQzr3US/M2A0UbMTfnmUU7BBx+kpRXZusA=; b=BQCUFI59D/h7jcdK5tvDkxkEEzIjL0s7vLikB+6TCniZVb22ErAozK6orxtLK0WX2K 6r2Y6aQCXU8s3qscJSDLdz3dVcotiE6hn13SrN7mcNZeV2x5ew0po5PghXeriSzzce/1 3r4lkdPwEVSBRm+Nx+6W33ttFPBsJP0fhQyVs2nXCviNUqvrO0KRE+37HP2wj2W+kWoD xj1I+Tamrxs9Ssse3IPexmbXTgPPH1roUBdvCmfL1zVAiAPQo37/oaO+ZiNTuGqcAMyy ZtawlUjsNyC2/PWwzTqpIVh9a7QyS9et6KgAoc9rB/ZgHAFguTCjdzmVQtWCvnxrOCnb 5aCA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j9-v6si473638pgt.16.2018.06.25.19.38.42; Mon, 25 Jun 2018 19:38:56 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755876AbeFZChn (ORCPT + 99 others); Mon, 25 Jun 2018 22:37:43 -0400 Received: from sauhun.de ([88.99.104.3]:48856 "EHLO pokefinder.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754175AbeFZChk (ORCPT ); Mon, 25 Jun 2018 22:37:40 -0400 Received: from localhost (unknown [91.73.131.157]) by pokefinder.org (Postfix) with ESMTPSA id D382556A487; Tue, 26 Jun 2018 04:37:37 +0200 (CEST) Date: Tue, 26 Jun 2018 11:37:36 +0900 From: Wolfram Sang To: Peter Rosin Cc: 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: <20180626023735.xj7aqhvw7ta2lq6s@ninjato> References: <20180620051803.12206-1-peda@axentia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180620051803.12206-1-peda@axentia.se> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thank you, Peter!