Hi! ... ... If error happens, would it make sense to propagate it back to the caller? Best regards, Pavel

Could this be moved near the patch it fixes? Or even merged to it? Introducing deadlocks is bad for bisection at the very least... Best regards, Pavel

Hi! I'd prefer this to be need the patch it fixes, too. Thanks, Pavel

Ok, but... Should the if ((chan > 8) || (chan < 0)) ever be true in practice? Sounds like bogus inputs to me. Should we dev_err() and return error in those cases? Or at least WARN_ON()? Best regards,

Ok, but again, could it be next to the patch it fixes? Thanks, Pavel

Hi! Thanks for the series. I'm currently reviewing it, I have some comments but nothing really bad so far. I'm now around the middle. Best regards, Pavel

Hi! Its too late to change that now, but 1/ fixes messages and then 2/ just deletes them. Single patch would do. Best regards, Pavel

Hi! clk = 0 initialization is never used. This is black magic. Where does 0x80000080 come from? Would it be possible to get some comment/explanation? What does bit 22 in clk mean? Should it go to temp

Hi! I'm not a great fan of function conversion to boolean here. With irqreturn_t it is clear what the values area; it is more ambiguous with the bool. And it is converted right back into irqreturn_t h

Hi! I'd add a comment here that gen2 allows fast clock changes ... and whatever other features the driver is actually using. Best regards, Pavel

Bool would make sense here, if the change is practical without changing too many interfaces... (and unless interface is something like 0/1/-ERRNO...) Best regards, Pavel

WIDTH_1 and WIDTH_8 would be better names, for consistency with rest of code. "WIDTH" without number is quite confusing. Best regards, Pavel

Hi! This is not quite english. And as of_data->tmio_ocr_mask is never written, I don't see how this can fix the problem effect. Best regards, Pavel

Hi! Is this removal intentional? I'm not sure from the changelog. Best regards, Pavel

Probably not worth changing any more, but it would be easier to review if it was merged with the first user. Best regards, Pavel

Hi! I don't see why tuning should depend on register size (thus sizeof(long)) of the host CPU. If 32 is enough, put 32 there... if not, just use 64? Or perhaps introduce a #define MAX_TAPS; it will be

In mainline, the commit removes the argument, as it says in the changelog. Not here in the backport. Why the difference? Best regards, Pavel

Hi! I'd somehow assume number of tuning parameters would be fixed... Does the hardware really change it? Out of curiosity, why is it doing so? Best regards, Pavel

Hi! This patch creates tmio_mmc_core.c ... ... which is already present in the Makefile before the patch. That can't be right. Best regards, Pavel

Patches 66 to 69 do a big rename while changing the code in question. That makes them hard / tricky to review. I should review that again, either now or in next version of the patch. Prototype changed