On 16.01.23 11:39, Marek Vasut wrote:
> On 1/11/23 08:38, Ahmad Fatoum wrote:
>> Hello Marek,
>
> Hi,
>
> [...]
>
>> Could you share your get_maintainers.pl invocation? I'd like to
>> adjust the reviewer entry in MAINTAINERS, so such patches get
>> into our kernel@xxxxxxxxxxxxxx inbox as well.
>
> Plain get_maintainer -f path/to/dts
>
>> Some more comments below.
>>
>>> + pmic: pmic@25 {
>>> + compatible = "nxp,pca9450c";
>>> + reg = <0x25>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_pmic>;
>>> + interrupt-parent = <&gpio1>;
>>> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
>>> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
>>
>> Here you assume GPIO1_IO04 is muxed as GPIO.
>>
>>> + pinctrl_usdhc2: usdhc2-grp {
>>> + fsl,pins = <
>>> + MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
>>
>> Here you mux it for USDHC2_VSELECT though. Is this intended?
>
> That's a good question, other DTs do the same thing, I suspect the
> sd-vsel-gpios could be dropped,
The sd-vsel-gpios is only needed when the hardware has an arbitrary GPIO
connected to the SD_VSEL signal of the PCA9450. IMHO, if SD_VSEL is
connected to the VSELECT signal it would be better to drop sd-vsel-gpios.
> but as long as it is not outright
> harmful, it can be used for backward compatibility to support less
> complete OSes which may not handle the eSDHC VSELECT bit , so I figured
> it is good to keep both options.
Would be interesting what OSes you have in mind? The eSDHC
driver/hardware should always handle the VSELECT signal, no?
