Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp1719025ima; Thu, 25 Oct 2018 03:57:27 -0700 (PDT) X-Google-Smtp-Source: AJdET5eskyMGoN/0BNBkLShiFgP6tDq18T5pMsSZjz+KOnDP9F9z9RojvV5+g7vPfz+R0N6JFbQ4 X-Received: by 2002:a63:4723:: with SMTP id u35-v6mr957055pga.95.1540465047458; Thu, 25 Oct 2018 03:57:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540465047; cv=none; d=google.com; s=arc-20160816; b=kmm0iHNpsG5VslSC6Yxkk3Da0olc+7ggSNu8k6a6RsCGjaEcfgJnLHmcRLzxhgKQww TkskG8ty/3OsyJa9gS3AbyP51JM7ku+YieXHjsCTVykoBZ8ox5j9LHJ/crME3xFHr6DP v+Y6el8ZpXLQHd7Kmk19TBjhOqdROaHyqei15AUzT/znNjpowCOmxMF4GMIuvQ6pDHs2 OZZSNwz9Cp0zd9Kv1kX+qEb9zOft9wpGzcz3LSwZTjfTvkcy8T7r6EIdoCipNdvjaGM4 zpyrDY+L8QmBC1sWb3f9t+svI0RhIhLz5E4Qs5kJJDDCnvL2Kwydob1Or3cx3pRNriL2 pW5g== 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; bh=/RYhUZKeCE4O3RnY/fRSRGHVu1Lgwa61Ej2h7RGAhOY=; b=bqXSuClqREIpzmR6kfQYGN1mJlOsldI1reEHpw24X66f89j1kCHTtHJSNl2f/QyQNj XO+gc346OQI6tl/tVJz99nsBlI9RWNMVZtDoUwisShqbkWcyvhUTVuSChALZvAYTYj4W /gD78PA4N2cXwX8C4FrReauJJDZ0oSHgT6MC7LaDySKFlFoSlYJSwVqFMgoe/Lypg7oG KLMpG0j/Nh02lXSTp5WbqQzZi3VH/7138w78kXUNAOULo2uOV/nUWV2rGAI/db8+XV1e XXIWgnMrQ42Fo6YTRtvQeJO6RA0tToVyNpv8b+OP6i/HjzmgoH3gNqY5Wvsiq2P3m/E7 NTTg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cirrus.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f63-v6si8430406pfb.0.2018.10.25.03.57.12; Thu, 25 Oct 2018 03:57:27 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cirrus.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727527AbeJYT2w (ORCPT + 99 others); Thu, 25 Oct 2018 15:28:52 -0400 Received: from mx0b-001ae601.pphosted.com ([67.231.152.168]:33190 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726852AbeJYT2w (ORCPT ); Thu, 25 Oct 2018 15:28:52 -0400 Received: from pps.filterd (m0077474.ppops.net [127.0.0.1]) by mx0b-001ae601.pphosted.com (8.16.0.23/8.16.0.23) with SMTP id w9PAsBDB012370; Thu, 25 Oct 2018 05:56:28 -0500 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.cirrus.com Received: from mail1.cirrus.com (mail1.cirrus.com [141.131.3.20]) by mx0b-001ae601.pphosted.com with ESMTP id 2n80speg0x-1; Thu, 25 Oct 2018 05:56:28 -0500 Received: from EX17.ad.cirrus.com (unknown [172.20.9.81]) by mail1.cirrus.com (Postfix) with ESMTP id D2226611E124; Thu, 25 Oct 2018 05:56:27 -0500 (CDT) Received: from imbe.wolfsonmicro.main (198.61.95.81) by EX17.ad.cirrus.com (172.20.9.81) with Microsoft SMTP Server id 14.3.408.0; Thu, 25 Oct 2018 11:56:27 +0100 Received: from imbe.wolfsonmicro.main (imbe.wolfsonmicro.main [198.61.95.81]) by imbe.wolfsonmicro.main (8.14.4/8.14.4) with ESMTP id w9PAuQmK007651; Thu, 25 Oct 2018 11:56:26 +0100 Date: Thu, 25 Oct 2018 11:56:26 +0100 From: Charles Keepax To: Mark Brown CC: Richard Fitzgerald , Lee Jones , , , , , , , , , , , Subject: Re: [PATCH v2 2/5] mfd: lochnagar: Add support for the Cirrus Logic Lochnagar Message-ID: <20181025105626.GE16508@imbe.wolfsonmicro.main> References: <20181008132542.19775-1-ckeepax@opensource.cirrus.com> <20181008132542.19775-2-ckeepax@opensource.cirrus.com> <20181025074459.GF4939@dell> <20181025082621.GD16508@imbe.wolfsonmicro.main> <20181025101248.GT2103@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20181025101248.GT2103@sirena.org.uk> User-Agent: Mutt/1.5.20 (2009-12-10) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810250098 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 25, 2018 at 11:12:48AM +0100, Mark Brown wrote: > On Thu, Oct 25, 2018 at 10:28:16AM +0100, Richard Fitzgerald wrote: > > On 25/10/18 09:26, Charles Keepax wrote: > > > On Thu, Oct 25, 2018 at 08:44:59AM +0100, Lee Jones wrote: > > > I really feel this isn't the driver you are objecting to as such > > > but the way regmap operates and also we seem to always have the same > > > discussions around regmap every time we push a driver. Is there > > > any way me, you and Mark could hash this out and find out a way to > > > handle regmaps that is acceptable to you? I don't suppose you are > > > in Edinburgh at the moment for ELCE? > > > I suppose if Mark was willing to promote the regmap drivers to be a > > top-level subsystem that could contain the regmap definitions of devices > > then we could dump our regmap definitions in there, where Mark can review > > it as he's familiar with regmap and the chips and the reasons why things > > are done the way they are, rather than Lee having to stress about it every > > time we need to create an MFD device that uses regmap. Though that would > > make the initialization of an MFD rather awkward with the code required > > to init the MFD it not actually being in the MFD tree. > > I'm not totally against dumping the data tables in some other directory > (we could do ../regmap/tables or whatever) but I fear it's going to > cause otherwise needless cross tree issues. I guess there is a question here, if i split the regmap stuff into a separate file within mfd would that be enough? Is it just the mixing of these tables and the code you object to Lee or is it the fact the tables exist at all? Thanks, Charles