From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760005AbdEVPvv (ORCPT ); Mon, 22 May 2017 11:51:51 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:52916 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752908AbdEVPvs (ORCPT ); Mon, 22 May 2017 11:51:48 -0400 Subject: Re: struct i2c_mux_pinctrl_platform_data for the i2c-mux-pinctrl driver To: Peter Rosin , Stephen Warren Cc: "linux-i2c@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <264eee82-8e0f-7d63-5c2f-e4070bf56c63@axentia.se> From: Stephen Warren Message-ID: <71dc13f9-f723-fb4b-a101-f7be8caacf1c@wwwdotorg.org> Date: Mon, 22 May 2017 09:51:46 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <264eee82-8e0f-7d63-5c2f-e4070bf56c63@axentia.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/22/2017 02:24 AM, Peter Rosin wrote: > Hi Stephen, > > I was looking at the i2c-mux-pinctrl driver and noticed that it has > code to feed it platform data from C code. There has never been any > in-kernel users of this interface and I would like to remove it. I > wonder if you added it way back when just because the i2c-mux-gpio > driver have such an interface or if, to your knowledge, any external > platform exists that depends on this? > > I.e. I'm talking about removing include/linux/i2c-mux-pinctrl.h and > the code supporting it in the driver, thus only allowing devicetree > as source for the platform data. I'm not aware of any in- or out-of-tree users of that structure/feature. I added it because at the time I wrote that driver, it was common place to support both DT-based and platform-data-based instantiation/configuration of devices, so I did the same. If you're removing pdata-based configuration, it would make sense to do a blanket removal across the entire I2C subsystem (and other subsystems too) I suspect, but that's LinusW's call in the end.