Sorry for the broken format in the last mail. Seems like thunderbird broke my setup after upgrading to v60...
Am 30.11.2018 um 16:30 schrieb Philipp Tomsich:
Tom,
On 30.11.2018, at 15:13, Philipp Tomsich <philipp.tomsich@theobroma-systems.com mailto:philipp.tomsich@theobroma-systems.com> wrote:
Simon,
On 30.11.2018, at 14:55, Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com mailto:simon.k.r.goldschmidt@gmail.com> wrote:
[cut down CC list as gmail won't let me send to that many people :-( ]
Sometimes I wonder if patman will at some point get a feature to avoid those endless CC lists for changes like this one.
Am 30.11.2018 um 12:39 schrieb Philipp Tomsich:
A number of MMC drivers uses BOUNCE_BUFFER for their DMA buffers. This moves it into Kconfig and performs a step-by-step migration for the affected boards/drivers.
In doing so, it turns out that a few boards/configs enabled CONFIG_BOUNCE_BUFFER in their config headers without an apparent need. The migration (using moveconfig) for those boards is kept in a separate patch, so it can be more easily reviewed by the affected parties to make a determination whether it is actually needed.
Given that BOUNCE_BUFFER only controls whether the bounce_buffer_* functions are build and linked, this configuration option could be entirely removed and the utility functions built unconditionally. For platforms that don't make use of these functions, the linker will then remove the unused symbols.
I'll leave the final decision if this would be a better implementation (or if this should be done in a two-stage process) to someone else... END.
I think this is a good idea, but I get build errors after applying patch 2/6 since CONFIG_BOUNCE_BUFFER is now enabled via Kconfig and defined as 1 while at the same time it is just defined (but to nothing) in socfpga_common.h.
This is a problem of having multiple individual patches for a moveconfig-style change. You need the final patch (6/6) in addition to (1/6) for socfpga.
Can you change or reorder this series so that every commit compiles?
There’s a couple options (none of they appeal to me): 1.I lump everything together into one big change. 2.I have a complete moveconfig (i.e. polluting all defconfig files) in the first patch and the individual changes to the MMC drivers then remove the defconfig entries for their platforms. 3.We skip this part of the conversion and directly skip forward to having bounce-buffer always included and leave the cleanup to the linker…
I’m happy to change this to any of the 3 options (although I’ll probably need a shower afterwards to feel less dirty, if we go with option #1 …)
I now tried option #2, but that leads to the final patch being subsumed into the first one (i.e. the maintainers of socfpga and the bcm* ports don’t get a chance to say “we confirm that this is not needed, just drop patch 6/6”).
So this boils down to whether Tom is ok with this being a series that has failures if not fully applied (i.e. patch 1/1 leaving loose ends that the follow-on patches address on a per-MMC-controller and per-platform basis)… …or if we skip the conversion and trust the linker to do the right thing.
Ok, in that case, I'll leave it up to Tom or others to decide.
Simon