Thread (15 messages) 15 messages, 4 authors, 2020-05-10

Re: [PATCH 1/3] regulator: max14577: Add proper dt-compatible strings

flat view

From: Krzysztof Kozlowski <krzk@kernel.org>
Date: 2020-02-24 20:13:03
Also in: lkml

On Mon, Feb 24, 2020 at 03:08:05PM +0100, Marek Szyprowski wrote:
Hi Mark,

On 21.02.2020 18:13, Mark Brown wrote:
quoted
On Fri, Feb 21, 2020 at 02:23:57PM +0100, Marek Szyprowski wrote:
quoted
On 21.02.2020 13:38, Mark Brown wrote:
quoted
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/ (local)

Best regards,
Krzysztof
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help