From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755684AbbIYJei (ORCPT <rfc822;w@1wt.eu>);
	Fri, 25 Sep 2015 05:34:38 -0400
Received: from mx0b-001ae601.pphosted.com ([67.231.152.168]:48421 "EHLO
	mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1755440AbbIYJeg (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 25 Sep 2015 05:34:36 -0400
Date: Fri, 25 Sep 2015 10:10:42 +0100
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Chanwoo Choi <cw00.choi@samsung.com>
CC: <lee.jones@linaro.org>, <robh+dt@kernel.org>, <pawel.moll@arm.com>,
        <mark.rutland@arm.com>, <ijc+devicetree@hellion.org.uk>,
        <galak@codeaurora.org>, <myungjoo.ham@samsung.com>,
        <sameo@linux.intel.com>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/6] extcon: arizona: Add device binding for second
 jack detect pin on GPIO5
Message-ID: <20150925091042.GD5432@ck-lbox>
References: <1442397404-7579-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
 <1442397404-7579-5-git-send-email-ckeepax@opensource.wolfsonmicro.com>
 <56049B42.7030509@samsung.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <56049B42.7030509@samsung.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000
 definitions=2015-09-25_04:2015-09-25,2015-09-25,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0
 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=7.0.1-1508030000 definitions=main-1509250149
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Sep 25, 2015 at 09:54:26AM +0900, Chanwoo Choi wrote:
> Hi Charles,
> 
> I have one comment.
> I think current extcon-arizona.c has the many platform data
> so, extcon-arizona.c use the too much if statement to support each feature
> for different wolfsonmicro codec. I think it cause the complicated code.
> 
> For example,
> You may use 'struct of_device_id' as following. You used already this method
> on drivers/mfd/arizona-core.c. If you separate the function of each wmXXXX arizona,
> it makes improved readability for extcon-arizona.c and some user will use extcon-arizora
> more easily.
> 
> struct arizona_extcon_data {
> 	void (*init)(...);
> 	void (*irq_handler)(...);
> 	...	
> };
> 
> struct arizona_extcon_data wm8994_data {
> 	.init = wm8994_extcon_init,
> 	.irq_handler = wm8994_extcon_irq_handler;
> 	...
> };
> 
> static const struct of_device_id arizona_extcon_dt_match[] = {
> 	{
> 		.compatible = "wm8994-arizona-extcon",
> 		.data = (void *)wm8994_data;
> 	}, {
> 		.compatible = "wmXXXX-arizona-extcon",
> 		.data = (void *)wmXXXX_data;
> 	}, 
> };
> 
> I expect that you will revise the arizona-extcon.c driver on next time.

I will have an investigation to see what ideas I can come up with
here and send through some patches.

But I am slightly worried you think the gains will be better than
they actually will be. Most of the platform data is just that
platform data, and needs to be configured based on the system not
based on the CODEC.

Thanks,
Charles