On Wed, Nov 06, 2019 at 09:53:40PM -0800, Saravana Kannan wrote: > On Mon, Nov 4, 2019 at 10:50 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > > > Sending again since the cover letter missed everyone/mailing lists. > > > > First two patches are just code clean up and logging with no functional > > difference. The 3rd patch adds support for the following DT properties: > > iommus, mboxes and io-channels. > > > > These patches are on top of driver-core-next since that's where the rest > > of the of_devlink patches are. > > > > Greg and Rob, > > On a side note, I was wondering if I should rename the of_devlink kernel > > command line to fw_devlink and move it out of drivers/of/property.c and > > into drivers/base/core.c. This feature isn't really limited to > > devicetree, so I don't see a need to have devicetree specific kernel > > command line option. Please let me know if that sounds okay to you. > > Hi Rob, > > Thanks for the reviews. Can you let me know what you think of this too? > > Rob/Greg, > > If I rename of_devlink to fw_devlink, I might also make it a setting > like fw_devlink=none/permissive/enforce > - none would be same as disabled completely. > - permissive would use SYNC_STATE_ONLY for all device links created by > firmware. So it won't block any probes even with cycles but > sync_state() will still work correctly. > - enforce would be the current "of_devlinkg=1" behavior where direct > dependencies would block probing and the child dependencies would use > SYNC_STATE_ONLY. Renaming makes sense to me, and all of the above is fine as well. thanks, greg k-h
