On 14:43-20130802, Sudeep KarkadaNagesha wrote:

On 01/08/13 17:49, Stephen Warren wrote:

quoted

On 08/01/2013 07:54 AM, Mark Rutland wrote:
...

quoted

We seem to be going over two cases, which both feel wrong to me:

* One SoC used in multiple boards, where on some boards an OPP cannot be
  used because some requirement is not met. In this case, the board's
  dts (by including the SoC's dtsi) describes something that's not
  necessarily usable, and we seem to have no way to describe in the OPP
  table that the OPP is not usable for that board.

There are probably a lot of examples of this already. For example, for
pinctrl, people often want the SoC .dtsi file to include "pin
configuration nodes" (see
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt) for many
common pinmux configurations in the SoC .dtsi file, so that board files
can simply refer to the already-existing nodes rather than having to
write everything from scratch. Obviously, not all common configurations
are used by every board.

...

Agreed, but I am not convinced with the comparison(pinmux and OPPs).
The main concern I have is that if some developer wants to experiment
with various configurations provided by SoC(e.g. I have seen some SoC
where the pinmux have multiple functions and you can chose one of them)
But that's not true with OPPs, if someone experiments with wrong OPP
profile, then it might damage the board permanently.

Even today, nothing prevents folks from "adding custom OPPs" at their
own personal risk here - We have seen folks do this as part of board
files - Now, for that matter, there is nothing that prevents folks
linking the wrong LDO or setting wrong LDO voltage and damaging the
board either.

I mean, at the level where we "describe" the hardware and it's
operation, you cannot be idiot or experimenter-proof - If these were
to be considered paramount and prevent us from choosing the right
concept that is needed for as many SoCs as possible, it'd be a shame.

-- 
Regards,
Nishanth Menon