On Mon, 08 Jun 2020, Andy Shevchenko wrote:

+Cc: some Intel people WRT our internal discussion about similar
problem and solutions.

On Mon, Jun 8, 2020 at 11:30 AM Lee Jones [off-list ref] wrote:

quoted

On Sat, 06 Jun 2020, Michael Walle wrote:

quoted

Am 2020-06-06 13:46, schrieb Mark Brown:

quoted

On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote:

quoted

Am 2020-06-05 12:50, schrieb Mark Brown:

...

quoted

Right.  I'm suggesting a means to extrapolate complex shared and
sometimes intertwined batches of register sets to be consumed by
multiple (sub-)devices spanning different subsystems.

Actually scrap that.  The most common case I see is a single Regmap
covering all child-devices.

Yes, because often we need a synchronization across the entire address
space of the (parent) device in question.

Exactly.

Because of the reasons in the paragraph above:

 "complex shared and sometimes intertwined batches of register sets to
  be consumed by multiple (sub-)devices spanning different subsystems"

quoted

 It would be great if there was a way in
which we could make an assumption that the entire register address
space for a 'tagged' (MFD) device is to be shared (via Regmap) between
each of the devices described by its child-nodes.  Probably by picking
up on the 'simple-mfd' compatible string in the first instance.

Rob, is the above something you would contemplate?

Michael, do your register addresses overlap i.e. are they intermingled
with one another?  Do multiple child devices need access to the same
registers i.e. are they shared?

quoted

quoted

quoted

But, there is more in my driver:
 (1) there is a version check

If we can rid the Regmap dependency, then creating an entire driver to
conduct a version check is unjustifiable.  This could become an inline
function which is called by each of the sub-devices instead, for
example.

quoted

quoted

quoted

 (2) there is another function for which there is no suitable linux
     subsystem I'm aware of and thus which I'd like to us sysfs
     attributes for: This controller supports 16 non-volatile
     configuration bits. (this is still TBD)

There is a place for everything in Linux.

What do these bits configure?

quoted

quoted

TBH I'd also say that the enumeration of the subdevices for this
device should be in the device rather than the DT, they don't
seem to be things that exist outside of this one device.

We're going circles here, formerly they were enumerated in the MFD.
Yes, they are devices which aren't likely be used outside a
"sl28cpld", but there might there might be other versions of the
sl28cpld with other components on different base addresses. I
don't care if they are enumerated in DT or MFD, actually, I'd
prefer the latter. _But_ I would like to have the device tree
properties for its subdevices, e.g. the ones for the watchdog or
whatever components there might be in the future.

[...]

quoted

MFD core can
match a device tree node today; but only one per unique compatible
string. So what should I use to differentiate the different
subdevices?

Right.  I have been aware of this issue.  The only suitable solution
to this would be to match on 'reg'.

FYI: I plan to fix this.

If your register map needs to change, then I suggest that this is
either a new device or at least a different version of the device and
would also have to be represented as different (sub-)mfd_cell.

quoted

Rob suggested the internal offset, which I did here.

FWIW, I don't like this idea.  DTs should not have to be modified
(either in the first instance or subsequently) or specifically
designed to patch inadequacies in any given OS.

quoted

But then, there is less use in duplicating the offsets in the MFD
just to have the MFD enumerate the subdevices and then match
the device tree nodes against it. I can just use
of_platform_populate() to enumerate the children and I won't
have to duplicate the base addresses.

Which is fine.  However this causes a different issue for you.  By
stripping out the MFD code you render the MFD portion seemingly
superfluous.  Another issue driver authors commonly contend with.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel