Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2818952ybv; Mon, 24 Feb 2020 12:13:21 -0800 (PST) X-Google-Smtp-Source: APXvYqyGCQgKlfkzzBpaLXTScygg75p211yWgGZlgPK2wrc3PGnDsxUAXQ4rJoQujNcDP6avWNH9 X-Received: by 2002:a05:6808:315:: with SMTP id i21mr592661oie.139.1582575201449; Mon, 24 Feb 2020 12:13:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582575201; cv=none; d=google.com; s=arc-20160816; b=TcuZIGyEw9wPx0GRG5F+prurwLShJzvj2RpCtorDWaYEgYT0rZBBITNRt6yRJwI0WY zV8okIk+OjbRHckqtWBWLRYpylJw7g/7b/Kp/G0DoTpU50oVyB8a7q319QsNjpXjJJ/O 1BgQ9W5w2dL6j4SUKMY1pjONU8kqPlpVbWGX9aO7l5R3BlHGRRmcj+VWYOy83q/0GUeq Cw91l58t5G3btr9ktmjSxtPJDFJKdN4SMgiO64eEwVQFmQa93RbCjApouZRDYuDTrdlO sp/T0ajrLxOOF536RlHtvMdu+ZnWWiuePPk7h+Y9jdoSdgrScFTnbvjRl7YQqjioYkTX AYcg== 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=TwCT11Q8st6DRF5f77QlbvmNTg2E5sCFURGACQNwpRo=; b=pnR96EUCjLTZ+obK6r84X68P7ReQv1VJlg1tvWp7OGJaEj+i5fYCD7uE0sICxwSiMZ RklR9UyOonm/XARfGZK4P1ydDmi4EPckklsEX3AUWvlXpmnmQ4fPrCLcFa9Z8ErXdbB7 WfzSd7L/UESw3hxn3cUgRkh3UFK1ubS+niLbGMY4G4T9y16pr+c/Ev0v3l6sCowidwNO 2cmhYEKLGKH0J3q4q4p2Skk+lul/xoGD8s8n8ZcufST8o09nqLIDr+YALVEUVdNxipnm 76Kr7djw27wYkjCW5rDLMAixVOQrCyDzeylkHZUk5A0ZGJpTaoZKdLtz69tr+i+0UDB9 HTuA== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l5si7114864otn.35.2020.02.24.12.13.08; Mon, 24 Feb 2020 12:13:21 -0800 (PST) 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727219AbgBXUNC (ORCPT + 99 others); Mon, 24 Feb 2020 15:13:02 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:41201 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726628AbgBXUNB (ORCPT ); Mon, 24 Feb 2020 15:13:01 -0500 Received: by mail-ed1-f68.google.com with SMTP id c26so13451500eds.8; Mon, 24 Feb 2020 12:13:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TwCT11Q8st6DRF5f77QlbvmNTg2E5sCFURGACQNwpRo=; b=M0qrcKD1M4eGLM7wE1bVijszZHCZ3HAstykQhGiAT8kwM8u1A9FA1M4/bnWGs2SSAh OntM4rK2t0bx1eZ6Sw2QpBNjWHAjZwm40zs8dqcLB/5QKPdLg+gVBgriIHgBxLeqiQGH mtkzawKMsPDG9So3snvEEO6qFzcSSsC6FFQAKTBFH9ym+/1F9lcSy9eePmGzYOLNdhO9 TEtWXhuBSb/BIcd1ep2Ok/JepZ9Ng4roi+GKiHpao87Y+cDWflKUHF5+Kpl+jHXxh6PX WsfHbUnTuD8OGBwOu7J621GKErKrMKzQMS6LIIZ8dmEb6Ys41qhHvQ02EHLcnqDMf4H+ X0Zg== X-Gm-Message-State: APjAAAU9VPfYo01EI2VXMD3RZzz/NZyPDrMzZo1mqary0+ox0yd4l30D TI1HIJd7M700ixCfF7hvfDQ= X-Received: by 2002:a17:906:2653:: with SMTP id i19mr47243420ejc.287.1582575180052; Mon, 24 Feb 2020 12:13:00 -0800 (PST) Received: from kozik-lap ([194.230.155.125]) by smtp.googlemail.com with ESMTPSA id d16sm1051538eds.18.2020.02.24.12.12.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 24 Feb 2020 12:12:59 -0800 (PST) Date: Mon, 24 Feb 2020 21:12:56 +0100 From: Krzysztof Kozlowski To: Marek Szyprowski Cc: Mark Brown , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Bartlomiej Zolnierkiewicz , Chanwoo Choi , MyungJoo Ham , Sebastian Reichel , Rob Herring Subject: Re: [PATCH 1/3] regulator: max14577: Add proper dt-compatible strings Message-ID: <20200224201256.GA8060@kozik-lap> References: <20200220145127.21273-1-m.szyprowski@samsung.com> <20200220165614.GD3926@sirena.org.uk> <964b8c4c-36ca-203d-e62b-4a8fc970e23d@samsung.com> <20200221123813.GB5546@sirena.org.uk> <20200221171342.GI5546@sirena.org.uk> <61dc8192-e313-021f-9e23-928257a66984@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <61dc8192-e313-021f-9e23-928257a66984@samsung.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 24, 2020 at 03:08:05PM +0100, Marek Szyprowski wrote: > Hi Mark, > > On 21.02.2020 18:13, Mark Brown wrote: > > On Fri, Feb 21, 2020 at 02:23:57PM +0100, Marek Szyprowski wrote: > >> On 21.02.2020 13:38, Mark Brown wrote: > >>> We could just remove the compatible strings from the binding > >>> documentation, they won't do any harm if we don't use them. > >> Frankly I have no strong opinion on this. I've just wanted to fix the > >> broken autoloading of the drivers compiled as modules. > > Shouldn't adding the relevant module table for the platform devices work > > just as well for that? Possibly also deleting the of_compatible bits in > > the MFD as well, ISTR that's needed to make the platform device work. > > Right. This will work too. MFD cells will match to their drivers by the > name and modalias strings will be correct. The question is which > approach is preffered? Krzysztof? I've checked other mfd drivers, but I > cannot find any pattern in this area. I would guess that adding MODULE_DEVICE_TABLE() for OF-matches in main MFD driver would fix the issue... otherwise the same problem we have with max77693 (also MUIC/extcon/regulator/charger). Some of these drivers (I guess only charger) bind to a OF node so they need a compatible. I think we added this to regulators and extcon for symmetry. Without this binding, the charger would need to read a specific child node from parent. This make them tightly coupled. It seems to me more robust for each component to bind to his own node, when needed. Another reason of adding compatibles was an idea of reusability of MFD children (between different MFD drivers or even standalone) but it never got implemented (children still depend on parent significantly). In general, I like the approach of children with compatibles but I will not argue against changing the drivers. They could really use some cleanup :) Long time I tried to remove the support for platform_data [1] - maybe let's continue? [1] https://lore.kernel.org/lkml/20170217200200.4521-1-krzk@kernel.org/ Best regards, Krzysztof