On 27 January 2016 at 14:23, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Wed, Jan 27, 2016 at 02:59:14PM +0200, Adrian Hunter wrote: >> In my view Ulf needs to explain how the SDHCI library is going to work, >> particularly in the absence of new callbacks. > > We need to add new callbacks as part of the conversion to a library, > otherwise we're very much into a total rewrite from scratch (which > I think is far too much work, and prone to errors) or a big flag day > to switch everything over (which will require a moritorium on sdhci > patches while the effort to switch everything is ongoing.) > > Both of those approaches suffer from one huge drawback: there is no > way to bisect between them to locate the cause of a regression. > > A piece-meal approach, where the driver is gradually converted is a > far saner approach, because it means that each conversion in the step > can be done as a series of transformations, which not only can be > properly reviewed, but also bisected - and that is _hugely_ important > for the existing state of SDHCI. > > The chances of some hardware behavioural quirk being missed while > trying to convert SDHCI to a library are _extremely_ high, and the > only sane approach to this is one which allows a progressive > transformation of the driver. > > Also, the last thing we want is for drivers to end up duplicating > entire functions from sdhci.c just because they have one thing > different (eg, because they need to do something in the middle of > a set_ios() call which no other SDHCI driver needs.) Having such > code duplication will just make maintanence even more of a > nightmare. > > set_ios() is probably one of the worst functions in sdhci right now, > and there's no obvious way to split it up into several stand-alone > functions which drivers could chain together. > > I think what needs to happen here is that Ulf needs to leave such > decisions about what is acceptable or unacceptable to those who are > trying to convert sdhci to a library, otherwise the conversion will > probably never happen... unless Ulf wants to get directly involved > in the conversion effort, producing patches to make it happen. > I don't intend to contribute much with actual patches. I am willing to help review and also help with expertise around the PM related parts. I do realize that some callbacks may still be needed, even in the end when sdhci has become a pure library. Although, those should be far less then those we have today. Currently I am more or less unable to properly maintain sdhci because of it's bad code structure. Therefore I have taken a quite simple approach by rejecting new callbacks and quirks, in a way to prevent it from being worse. To me, the best way forward would be if some of you experienced sdhci developers stepped in as a maintainer for it. In that way, I can trust the development moving in the "library direction" so I can pull back from nacking potential interim sdhci callbacks/quirks. Does it make sense? Kind regards Uffe -- 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
