Hi Markus, > Now I have a question (or rather a comment) of my own. I noticed that > you "squashed" my two original patches into a single patch before > breaking out the debugfs related code. The side-effect of this was > that two lines of my bcm_defconfig change (CONFIG_WATCHDOG=y and > CONFIG_BCM_KONA_WDT=y) were included in the patch you took into > linux-watchdog-next. > > If I understand correctly (and this is why I had broken out the > bcm_defconfig change into a separate patch), a defconfig change would > normally go through the platform maintainer's tree, in this case > Christian, whereas the actual driver would go upstream through your > tree. > > I don't think it makes too much of a difference with regards to this > driver where the defconfig change goes. In fact, taking it all through > one tree might even be slightly easier and reduce the chance of > conflicts, but I still think Christian needs to at least be aware of > this change going through the watchdog tree. He owns bcm_defconfig, > after all.
If it is an existing driver then it makes sense to go through the platform maintainer's tree. If it is a new driver then I prefer to keep it as one patch. Suppose the defconfig stuff get's in via the platform tree and I don't sent the watchdog driver; would be an annoying situation in my opinion... So that's why I prefer it as a single patch. Kind regards, Wim. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
