On Wednesday 20 April 2016 15:32:56 David Daney wrote: > > > > For A): > > I have suggested a solution that I think can be generic, see my earlier email. > > > > From the DTB point of view, I request you to update the slot > > compatible string to a generic one. Is that a difficult task to patch > > the DTB with? > > It depends on the length of the new compatible property. If it is > longer than the old property, then it is much more difficult. > > > > If so, let's keep yours as well, but make sure it's documented as deprecated. > > > > Regarding the changes needed to the mmc core, as to enable it to know > > about mmc-slots, this should be quite easy to implement. I even > > volunteer to can help, if you think it's needed. > > > > So to summarize regarding A). I want a generic solution for slot nodes! > > > > For B), there are two cases: > > 1. Legacy bindings that already has a corresponding generic MMC > > binding. Renaming these properties by patching the DTB is an easy > > operation. > > It is not so easy to rename things in the DTB. Any renaming causes the > string table to grow, so you have to have to allocate extra space for > it. Currently everything we do with the DTB is done in-place, so you > would have to rewrite the early DTB handling code to allocate memory and > make a copy of the DTB. Doesn't libfdt do both of these things for you? I was expecting that you could just call fdt_setprop() and fdt_set_name(), but I have not tried this myself. On ARM, we actually modify the in-kernel devicetree representation after unflattening, see e.g. arch/arm/mach-mvebu/kirkwood.c for a file calling of_update_property(), but it seems that octeon does its fixups at an earlier stagge using libfdt. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
