On 27 September 2013 00:16, Grant Grundler <grund...@chromium.org> wrote: > On Thu, Sep 26, 2013 at 2:56 PM, Grant Grundler <grund...@chromium.org> wrote: >> On Wed, Sep 25, 2013 at 7:37 PM, Chris Ball <c...@laptop.org> wrote: >>> Hi, >>> >>> On Wed, Sep 25 2013, Chris Ball wrote: >>>> Hi, >>>> >>>> On Fri, Sep 20 2013, Ulf Hansson wrote: >>>>> On 19 September 2013 19:20, Grant Grundler <grund...@chromium.org> wrote: >>>>>> struct mmc_queue defines issue_fn as an indirect function call. >>>>>> issue_fn field only gets set to mmc_blk_issue_rq and only gets >>>>>> invoked immediately after calling blk_fetch_request(). >>>>>> Don't bother with indirect function call - it's pointless and just >>>>>> obfuscates the code. >>>>>> >>>>>> Signed-off-by: Grant Grundler <grund...@chromium.org> >>>>> >>>>> Acked-by: Ulf Hansson <ulf.hans...@linaro.org> >>>> >>>> Thanks, pushed to mmc-next for 3.13. >>> >>> Have dropped this, it's breaking my build: >>> >>> /home/cjb/git/mmc/drivers/mmc/card/block.c:1955:12: warning: >>> ‘mmc_blk_issue_rq’ defined but not used [-Wunused-function] >> >> The function is declared static. :( Let me respin to remove the >> static and add a function prototype to a header file. > > block.o and queue.o are linked together into one .ko all the time: > obj-$(CONFIG_MMC_BLOCK) += mmc_block.o > mmc_block-objs := block.o queue.o > > Two ways to handle this: I can > 1) add a local function prototype of mmc_blk_issue_rq() to queue.c > 2) move mmc_init_queue() and mmc_queue_thread() from queue.c to block.c > > (2) actually makes sense since both functions are block IO specific. > > Thoughts? Preference? Other ideas?
Hi Grant, Generally I am in favour of cleaning up messy code. But in this case it now seems a bit overworked. How about actually leaving it as is? Kind regards Ulf Hansson > > thanks, > grant > > ps. It's more obvious now that the return value from > mmc_blk_issue_rq() is getting ignored. *sigh* -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
