On Thu, Jan 19, 2017 at 6:11 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> wrote: > On Thu, Jan 19, 2017 at 05:58:10PM +0100, Ulf Hansson wrote: >> + Russell >> >> On 16 January 2017 at 08:37, Andrea Merello <andrea.merello@xxxxxxxxx> wrote: >> > The STM32F4xx family contain a SDIO IP that looks like a variant of >> > the PL180, however, inspite it's actually attached to a APB bus, it >> > cannot be handled by the AMBA bus code, because it lacks of the ID >> > registers that AMBA primecell IPs have. >> > >> > This patch prepares for supporting the STM32 variant by letting the >> > driver register also as a platform driver, that can be matched from >> > the OF with specific "compatible" strings >> >> NAK! > > Also NAK. > >> Too much code are depending on the amba bus in the driver. I sincerely >> hope you haven't tried this approach for other amba drivers, because >> it will screw them up and they will become a nightmare to maintain! It's almost only probe/remove code.. Nothing in the core of the driver gets involved here.. What about splitting the driver in three files (mmci.c, mmci_amba.c and mmci_plat.c) and compile them conditionally? BTW This approach is not my invention; there is at least another driver in mainline kernel that does that: amba-pl011.c >> Moreover, there is a way to override the use of the AMBA IDs >> registers. I think you can use that instead! No? > I'm aware of it; I used it as a quick hack to get the driver probed, but that looked just like as an hack to me.. > Exactly right. Nothing wrong with creating an amba device in response > to probing a platform device - which becomes a shim which keeps the > main driver clean and maintanable. The shim could also be used to > create amba device for other AMBA drivers too, it doesn't have to be > MMCI specific. If we ovverride the amba regs from DT (is this what you meant?) then we just take a random number, prentend it to be an amba ID (hoping for it to be spare), and use it to force the amba bus layer to probe our driver. How can we make this common for other drivers/devices ? We need it to be unique, since it's used by the amba layer to probe the correct driver (given the generic "arm,primecell" compatible DT property), or am I missing something ? > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. -- 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
