linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Mark Brown <broonie@kernel.org>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	Sebastian Reichel <sre@kernel.org>,
	Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH 1/3] regulator: max14577: Add proper dt-compatible strings
Date: Fri, 6 Mar 2020 14:51:22 +0100	[thread overview]
Message-ID: <791edb65-4471-3e54-6806-4af2876fea19@samsung.com> (raw)
In-Reply-To: <20200224201256.GA8060@kozik-lap>

Hi Krzysztof,

On 24.02.2020 21:12, Krzysztof Kozlowski wrote:
> On Mon, Feb 24, 2020 at 03:08:05PM +0100, Marek Szyprowski wrote:
>> 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).

Indeed, there is a same problem with max77963:

max77963-muic driver lacks compatible and has wrong platform modalias 
("extcon-max77963"),

max77963-charger driver lacks compatible,

max77963-haptic driver lacks compatible.

> 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.

Extcon would also need its node when support for it will be added to 
dwc2 driver. Having compatible strings in the nodes simplifies matching 
and makes it almost automatic.

> 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).

So far, there is no such case.

> 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/

Cleanup of the driver is another story, completely independent of fixing 
this issue imho.

krzk: could you then specify if you are against or after the proposed 
changes?

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


  reply	other threads:[~2020-03-06 13:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200220145134eucas1p288ae1910d3e8d12dc12f010ed0b07b45@eucas1p2.samsung.com>
2020-02-20 14:51 ` [PATCH 1/3] regulator: max14577: Add proper dt-compatible strings Marek Szyprowski
     [not found]   ` <CGME20200220145135eucas1p123c4e4523e7e6eb86b64e728d6931cee@eucas1p1.samsung.com>
2020-02-20 14:51     ` [PATCH 2/3] extcon: " Marek Szyprowski
2020-03-14 18:45       ` Krzysztof Kozlowski
     [not found]   ` <CGME20200220145135eucas1p1ba181cef65c7a4f91a254ee35e022f08@eucas1p1.samsung.com>
2020-02-20 14:51     ` [PATCH 3/3] power: charger: " Marek Szyprowski
2020-03-14 18:45       ` Krzysztof Kozlowski
2020-05-10 16:54       ` Sebastian Reichel
2020-02-20 16:56   ` [PATCH 1/3] regulator: " Mark Brown
2020-02-21 10:44     ` Marek Szyprowski
2020-02-21 12:38       ` Mark Brown
2020-02-21 13:23         ` Marek Szyprowski
2020-02-21 17:13           ` Mark Brown
2020-02-24 14:08             ` Marek Szyprowski
2020-02-24 20:12               ` Krzysztof Kozlowski
2020-03-06 13:51                 ` Marek Szyprowski [this message]
2020-03-14 18:41                   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=791edb65-4471-3e54-6806-4af2876fea19@samsung.com \
    --to=m.szyprowski@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=broonie@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=robh+dt@kernel.org \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).