Re: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support

[Sekhar Nori]

On 08/12/18 9:24 PM, Nishanth Menon wrote:
> On 14:12-20181207, Faiz Abbas wrote:
> 
>> +
>> +&sdhci0 {
>> +	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&main_mmc0_pins_default>;
>> +	bus-width = <8>;
>> +	non-removable;
>> +	ti,driver-strength-ohm = <50>;
> 
> ^^
> 
>> +};
>> +
>> +&sdhci1 {
>> +	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&main_mmc1_pins_default>;
>> +	ti,driver-strength-ohm = <50>;
> 
> NAK.
> 
> $ git checkout next-20181207
> $ git grep ti,driver-strength-ohm Documentation
> $
> 
> Nada.. And.. I think "new phy binding" probably introduces this.
> [1] https://patchwork.kernel.org/project/linux-mmc/list/?series=53185
> 
> If your patches are'nt really ready, please send them as RFC, I am not
> really in a mood to track the status of every single driver subsystem.
> 
> If your binding is not in linux next at the baremin, as far as I am
> concerned, this is not ready, and should be RFC.

No, RFC does not say "do not merge" or "this has dependencies". RFC is
used to invite a stronger review when introducing a new concept. Its
fair game to apply patches marked RFC if maintainer is okay with the
content.

Dependencies are either noted in cover-letter or below the patch
tear-line. With what you are asking, looks like patches need to be
resubmitted once dependencies are cleared, even if there is no change in
the content itself. This will be additional work.

That said, if it makes life convenient for you, you can impose such a
rule for patches you need to handle. But I think it will take some
getting used for developers who send patches to you as I don't think
this is a norm elsewhere.

Adding Tony and Arnd as well, in case I have missed some recently
accepted convention.

Thanks,
Sekhar