Hi Boris,
2016-11-28 0:12 GMT+09:00 Boris Brezillon <[email protected]>: > On Sun, 27 Nov 2016 03:05:50 +0900 > Masahiro Yamada <[email protected]> wrote: > > Please add a description here. > > Also, this commit tends to validate my fears: you should have wait for > the full rework/cleanup to be done before submitting the first round of > cleanups. Indeed, commit c4ae0977f57d ("mtd: nand: denali: remove unused > struct member denali_nand_info::idx") was removing one of these unused > fields, leaving 2 of them behind. Right. No difference except that denali->idx was initialized to zero(, but not referenced). I could squash the two patches. > While I like when things I clearly separated in different commits, when > you push the logic too far, you end up with big series which are not > necessarily easier to review, and several commits that are achieving > the same goal... I must admit that I hurried up in posting the first round. But, please note I did not ask you to pick it up for v4.10-rc1. After all, it was your choice whether you picked it soon or waited until you saw the big picture. You could have postponed it until v4.11-rc1 if you had wanted. My idea was, I'd like to get feedback earlier (especially from Intel engineers). I fear that I do not reveal anything until I complete my work. If I am doing wrong in the early patches in my big series, I might end up with lots of effort to turn around. I dropped various Intel-specific things, for example commit c9e025843242 ("mtd: nand: denali: remove detect_partition_feature()") removed the whole function I do not understand. There was possibility that it might be locally used by Intel platforms. If I had gotten negative comments for removal, I'd have needed more efforts to not break any old functions. As a result, nobody was opposed to delete such things. So, I can confidently continue my work on cleaner and more *stable* base. -- Best Regards Masahiro Yamada

