dts: stepper: move m0/m1-gpios property in stepper-controller

[jilaypandya]

m0-gpios and m1-gpios are common in step-dir stepper drivers and hence placing them in common stepper-controller.yaml along with step-gpios and dir-gpios

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dipakgmx]

This solution does not seem extensible. Drivers like A4988, DRV8825 support 3 pins for setting micro-stepping which would not work (or, say extend), in this case. A possible solution, would be to revert to the phandle logic for the microstepping pins, like earlier:

microstep-mode-gpios:
    type: phandle-array
    description: GPIO specifiers for microstepping pins.

& use the existing

  micro-step-res:
    type: int
    default: 1
    enum:
      - 1
      - 2
      - 4
      - 8
      - 16
      - 32
      - 64
      - 128
      - 256
    description: |
      micro-step resolution to be set while initializing the device driver.
      Use this only if the MS pins are hardwired to VCC/GND.

to determine the microstepping resolution in the case of hardwired pins.

Also, we can then enforce this exclusivity in the driver level (eiither set via gpio's or hardwired(static)).

[jilaypandya]

One could hardwire one pin, while still toggling the others via gpio. In this scenario, the idx of the pin getting toggled via gpio is important to know.The available micro-step resolutions would be reduced, but the application would still have the possibility to select.

We can extend the list as soon as one of the aforementioned drivers gets upstreamed.

[jbehrensnx]

Hardwiring only 1 microstep pin but leaving the others feels like a serious edge case. At that point having the user set the microstep resolution manually would be something I am fine with. In addition, drv84xx and tmc22xx are currently all or nothing in regards to microstep pins while the allegro currently requires the microstep pins (that should be fixed at some point).

[dipakgmx]

One could hardwire one pin, while still toggling the others via gpio. In this scenario, the idx of the pin getting toggled via gpio is important to know.The available micro-step resolutions would be reduced, but the application would still have the possibility to select.

We can extend the list as soon as one of the aforementioned drivers gets upstreamed.

Ok, but this does seem contra-intuitive to me, since phandles provide the flexibility of any large number of gpios to be inserted.
Also, it seems like #100384 is also on similar lines, so I suppose this change of logic is underway, so I guess, this needs to be standardised now.