On Sun, Jan 8, 2023 at 11:58 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > Hi, > > * Adam Ford <aford173@xxxxxxxxx> [230105 19:20]: > > On Thu, Jan 5, 2023 at 1:08 PM Adam Ford <aford173@xxxxxxxxx> wrote: > > > On Thu, Jan 5, 2023 at 12:17 PM H. Nikolaus Schaller <hns@xxxxxxxxxxx> wrote: > > > > Am 05.01.2023 um 18:54 schrieb Adam Ford <aford173@xxxxxxxxx>: > > > > > > > > Would there be an objection if I migrate the OMAP3.dtsi file to the > > > > newer driver? I wasn't sure if there was a reason this family was > > > > being held back from the newer driver. > > > > > > > > > > > > AFAIR Tony wanted to retire the older driver anyways. > > > > > > That was my impression and it appears that the AM35x has already > > > > correction AM335x (not AM35x) > > > > > migrated to it. I wasn't sure what was holding us back. In theory, > > > we could add the compatible flags to the new driver and mark them as > > > deprecated so the new driver would work with older device trees if > > > there was push-back on changing the device trees. I know sometimes > > > there are concerns about using older device trees and the interaction > > > with the compatible flags make it a bit more complex. > > Things should be ready to flip the remaining SoCs to use sdhci so we > should do that. > > The only thing I'm aware of is that sdhci will try to keep probing > also mmc instances that are not wired. So some board specific dts files > may need to set some mmc instances with status = "disabled". Or maybe > the sdhci driver can be configured to stop trying after some timeout. > > Regards, > > Tony
