Hi Nishanth, On 10/12/18 5:36 PM, Nishanth Menon wrote: > On 13:33-20181210, Sekhar Nori wrote: >> 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. > > True, fair enough.. RFC is request for comments. Anyways, that is > besides the point. >> >> 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. > > Yes please. There would be other dts changes that are probably ready and > I really wont be tracking everything happening on other drivers. If the > binding is present at least in next, it is a good indication of things > clean and ready to go. Agree that bindings should be in linux-next before device-tree files are merged. > >> >> 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. > > > I have'nt looked at any conventions, The style I prefer to follow when I do > submissions: It is my job to get the bindings in, until then my actual > dts is just "request for comments". Only after the bindings are merged > do I formally submit dts - simply because I dont expect dts maintainer > to track what happened to my driver's binding and discussions there of. Ok. > > Seriously, is'nt it really reasonable for dts maintainer to check every > single driver's development status in 15 different mailing lists? > Because, it sounds like what you are asking. At least I wont have time > for it.. > > > I really am curious how Arnd / Tony actually pull this one off.. If they > have continous cron job for checking if your patch is ready... I doubt > it.. I think you can rely on the author to tell you when something is actually ready to be merged (and you can tell him/her to remind you). For the review itself, doing it by having a look at the dependencies mentioned in the cover letter (like available for this series) should be good enough (I feel). I am not sure if there is a need to post an "RFC version", and then follow it up with an actual "PATCH version" once dependencies are cleared though. Thanks, Sekhar