From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Sverdlin Subject: Re: [PATCH v2] of: i2c: Add idle-disconnect DT property to PCA954x mux driver Date: Thu, 15 Jan 2015 14:09:09 +0100 Message-ID: <54B7BBF5.4010001@nsn.com> References: <5494599A.8050803@nsn.com> <20150115123237.GC2549@katana> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150115123237.GC2549@katana> Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: ext Wolfram Sang Cc: jdelvare-l3A5Bk7waGM@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Laurent Pinchart , Rob Herring , grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Lawnick Michael 61283229 , Maxime Ripard , Stephen Warren List-Id: devicetree@vger.kernel.org Hi Wolfram! On 15/01/15 13:32, ext Wolfram Sang wrote: > On Fri, Dec 19, 2014 at 06:00:10PM +0100, Alexander Sverdlin wrote: >> of: i2c: Add idle-disconnect DT property to PCA954x mux driver >> >> Add idle-disconnect device tree property to PCA954x mux driver. The new property >> forces the multiplexer to disconnect child buses in idle state. This is used, for >> example, when there are several multiplexers on the same bus and the devices on >> the underlying buses might have same I2C addresses. > > Basically OK. Question to DT maintainers: "idle-disconnect", > "i2c-mux-idle-disconnect", or is there another existing binding we could > use? > >> At the same time old (and not used in the tree) platform data binding >> deselect_on_exit is removed to simplify the implementation. Old binding has >> different (per-channel) semantics and doesn't fit well in the new concept. > > I'd prefer to keep it. It should be only one || more. It is not really > in the way IMO. It complicates the implementation 3x times :) This is part of our discussion with Laurent: ---- >> >> I would copy pdata->modes[chan].deselect_on_exit to data->idle_disconnect >> in the probe function, so you could avoiding accessing pdata here. > > Unfortunately, this pdata has different (per-channel) semantics. I cannot > really understand, why it was done this way, but anyway it's not possible > to use one global bit to represent per-channel bits without changing the > behavior. > > I'm not keen to brake out-of-tree code (if any), but may be it will be > decided to drop this per-channel deselect_on_exit, because it's not used at > least in the kernel tree... I'd vote for removing deselect_on_exit from platform data, but I won't insist. ---- -- Best regards, Alexander Sverdlin.