On 04.02.2023 23:56, Martin Blumenstingl wrote: > Hi Heiner, > > On Wed, Feb 1, 2023 at 11:13 PM Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote: > [...] >>>> + - items: >>>> + - const: amlogic,meson8m2-aobus-pinctrl >>>> + - const: amlogic,meson8-aobus-pinctrl >>>> + - items: >>>> + - const: amlogic,meson8m2-cbus-pinctrl >>>> + - const: amlogic,meson8-cbus-pinctrl >>> >>> Again, can't have both with and without the fallback allowed. >>> >> Hi Martin, >> >> meson8m2 is the only chip version having a fallback for the >> pinctrl compatible. Is this fallback really needed? >> Looking at the driver it seems that both compatibles >> are handled identically. > Back in the day we decided to duplicate the Meson8 driver code just to > add four new pin functions that are added by the Meson8m2 SoC > generation: > "eth_rxd2", "eth_rxd3", "eth_txd2", "eth_txd3" > > The compatible string was defined with a similar approach: since > Meson8m2 just adds a few bits to the Meson8 pin controller it's > backwards compatible. > > If the fallback has to be removed then I'm okay with that but I would > like to understand it first. > So far I thought that Rob basically asked to remove the following two > compatible strings from the enum (as they're listed separately with > their fallbacks): > - amlogic,meson8m2-cbus-pinctrl > - amlogic,meson8m2-aobus-pinctrl > Right, this should be sufficient. There's no place where the 8m2 pinctrl compatibles are used w/o fallback. Then the hopefully final version of the binding is almost ready. I'm just still checking whether there's any way in yaml to specify a reg-names list with mandatory and optional names. Doesn't seem so. > > Best regards, > Martin Heiner
