On Mon, Sep 16, 2013 at 3:50 PM, Brian Norris <computersforpeace@xxxxxxxxx> wrote: > On Mon, Sep 16, 2013 at 3:28 PM, Olof Johansson <olof@xxxxxxxxx> wrote: >> Guys, >> >> On Fri, Sep 13, 2013 at 11:21 AM, Brian Norris >> <computersforpeace@xxxxxxxxx> wrote: >>> + devicetree@xxxxxxxxxxxxxxx >>> >>> On Fri, Sep 13, 2013 at 05:28:13PM +0800, Josh Wu wrote: >>>> On 9/12/2013 7:02 AM, Brian Norris wrote: >>>> >On Tue, Sep 03, 2013 at 05:20:27PM +0800, Josh Wu wrote: >>>> >>Since following commit >>>> >> f3b391425d21e6138e57b2432d91134e0bc2b975 >>> >>> ... >>> >>>> >> (of_mtd: Add no-op stubs to support CONFIG_OF=n) >>>> >> >>>> >>implements the stub for CONFIG_OF=n. Now we can safely remove all >>>> >>CONFIG_OF in atmel_nand. (Thanks to Ezequiel Garcia's for this protype) >>>> >I'm not quite so sure about this patch, as I was about the pxa3xx patch. >>>> >With pxa3xx, the compiler can easily tell that pxa3xx_nand_probe_dt() >>>> >will return 0 without doing anything in the !CONFIG_OF case (and so will >>>> >likely remove the dead code), so it's no benefit to have the #ifdef. But >>>> >in this driver, the atmel_of_init_port() function can't be trivially >>>> >determined to do nothing (and in fact, it does something in either >>>> >CONFIG_OF=y or =n case). It's only protected by the 'if >>>> >(pdev->dev.of_node)' check, which the compiler can't predict. >>>> >>>> I understand your concern here. >>>> >>>> > >>>> >So, I don't know if we should remove the #ifdef at the expense of likely >>>> >significantly larger code. I won't protest, but I won't merge it yet >>>> >either. Perhaps others have better ideas, or perhaps you can find a good >>>> >way to work around this -- e.g., check the of_* helpers for -ENOSYS early >>>> >in atmel_of_init_port()? >> >> >> Can we please get less fumbling around on this and just merge a fix, >> please? You guys have broken the PXA3xx builds for the whole merge >> window, while there's been a patch sitting in linux-next with >> _exactly_ this contents since August 30, committed by David. > > How about you read the thread you're responding to? This is a > different driver, and it is not broken. Ah, oops, my apologies. I came across this when searching for the (committed) patch in my mail history and didn't notice the driver name differences. :) > If you look at the thread for the patch which fixes the actual > breakage (in pxa3xx), you will see a plain and clear explanation of > the situation. > > http://lists.infradead.org/pipermail/linux-mtd/2013-September/048595.html > http://lists.infradead.org/pipermail/linux-mtd/2013-September/048598.html > > David has been sufficiently notified, and he is not acting. I have > even pinged him on our IRC channel, with no response, although I'm not > surprised. > > (BTW, I assume the "committed by David" is simply because of > git-rebase. It doesn't necessarily reflect his acknowledgment of the > patch. I can only assume that it was an oversight on his part.) That in itself seems broken; if he is pulling code from you he shouldn't rebase. >> If this is't fixed within the next few days I'll just pick that patch >> up and include it in our next batch of arm-soc fixes. This is >> ridiculous. > > My hands are tied, as the only thing I could do would be to submit a > pull request around David's back. I am just as frustrated as you, but > for different reasons. The (lack of) response from the head MTD > maintainer is unacceptable, IMO, and it is a recurring problem that we > are trying to solve by my involvement as a submaintainer. But > merge-window problems are not quite under my authority... What you could do is send just a patch, not a pull request. But anyway: > Anyway, I don't care if the patch goes in via another tree, as long as > this debacle (notably, for the pxa3xx_nand driver, not the atmel_nand > driver) is resolved. Ok. Russell was asking what the status of the fix was as well. I'll queue it up with our current fixes for -rc2. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
