...

quoted

* The enumerations above should be purely at the level the HW exposes,
i.e. if a UART uses 4 signals (RX, TX, CTS, RTS), and the SoC
configures muxing at a per-pin level, and 6 pins exist which can have
various UART signals mux'd on to them, there should be a "muxable
entity" enumeration for each of the 6 pins, not an enumeration for
each possible combination of assignments of signals to pins, since in
general that number could be extremely large as Richard Zao points out
in his email that was sent right after yours.

Speaking of the model, yes, it's true.  But coming to the practical
implementation, we may need compromise on whether we need to do a full
enumeration.

quoted

* pinmux properties in device drivers should list the muxable entities
that they use, and the mux function for each of them.

Following on the example above, we will need something below in SD node to
specify each pin and corresponding function selection.

        usdhc at 02194000 { /* uSDHC2 */
                #pinmux-cells = <2>;
                // The second cell specify the index of the desired function of
given pin
                pinmux = < &sd2_dat1 0
                           &sd2_dat2 0
                           ...        >;
                status = "okay";
        };

IMO, it's not nice for pinctrl client devices.  Though it's true that the
muxable entity is pin, what the client device really cares is its pingroup.  We
should define the pingroup rather than pin for client device to refer to with a
phandle.  This is just like that pinctrl subsystem api pinmux_get/enable operate
on a pingroup as an interface to client device driver, no matter the muxable
entity at HW level is a pin or a group.

+1
It's just like what the current pinctrl subsystem does:
the device says "I'm using this function and this pin group, please enable!"
But no pins are specified.

Regards
Dong Aisheng