On Wed, Feb 04, 2026 at 09:05:34AM +0100, Andy Shevchenko wrote:

On Wed, Feb 04, 2026 at 12:34:36AM +0100, Linus Walleij wrote:

quoted

On Tue, Feb 3, 2026 at 5:17 PM Conor Dooley [off-list ref] wrote:

quoted

quoted

pinconf_generic_dt_node_to_map_pinmux() is not actually a generic
function, and really belongs in the amlogic-am4 driver. There are three
reasons why.

(...)

quoted

The other dt_node_to_map implementations accept a being called for
either a node containing pin configuration properties or a node
containing child nodes that each contain the configuration properties.
IOW, they support the following two devicetree configurations:

| cfg {
|       label: group {
|               pinmux = <asjhdasjhlajskd>;
|               config-item1;
|       };
| };

| label: cfg {
|       group1 {
|               pinmux = <dsjhlfka>;
|               config-item2;
|       };
|       group2 {
|               pinmux = <lsdjhaf>;
|               config-item1;
|       };
| };

pinconf_generic_dt_node_to_map_pinmux() only supports the latter.

This alone is a good reason to apply the patch.

I have a strong urge to apply this already for v7.0 despite its RFC state.

Anyone against?

I forgot to say that I had made it rfc cos of where in the cycle we are
and the fact that I didn't test it. I've got no objection though if
that's what you want to do.

Quite the opposite! I fully support unloading pin control core from OF-centric
code.

Note, please, remove extra '.' (dot) in the Subject.o

fwiw, the .. was intentional cos I was truncating the pinconf_generic
from the function since the subject was really long, not referring to
a member of an ops struct.

Acked-by: Andy Shevchenko <redacted>