On Tue, 2013-11-19 at 13:57 -0500, Bruce Ashfield wrote: > On 13-11-19 12:17 PM, Paul Butler wrote: > > > > On Sat, Nov 9, 2013 at 9:49 AM, Bruce Ashfield > > <bruce.ashfi...@windriver.com <mailto:bruce.ashfi...@windriver.com>> wrote: > > > > On 11/7/2013, 8:13 PM, Paul Butler wrote: > > > > From: John Jacques <john.jacq...@lsi.com > > <mailto:john.jacq...@lsi.com>> > > > > Signed-off-by: John Jacques <john.jacq...@lsi.com > > <mailto:john.jacq...@lsi.com>> > > --- > > drivers/net/ethernet/lsi/lsi___acp_mdio.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/net/ethernet/lsi/__lsi_acp_mdio.c > > b/drivers/net/ethernet/lsi/__lsi_acp_mdio.c > > index 04c224c..18aaba1 100644 > > --- a/drivers/net/ethernet/lsi/__lsi_acp_mdio.c > > +++ b/drivers/net/ethernet/lsi/__lsi_acp_mdio.c > > @@ -98,6 +98,11 @@ acp_mdio_read(unsigned long address, unsigned > > long offset, > > *value = (unsigned short)(command & 0xffff); > > spin_unlock_irqrestore(&mdio___lock, flags); > > > > +#if 0 > > + printk("%s - Read 0x%x from 0x%x register 0x%x\n", > > + __FUNCTION__, *value, address, offset); > > +#endif > > + > > return 0; > > } > > EXPORT_SYMBOL(acp_mdio_read); > > @@ -150,6 +155,11 @@ acp_mdio_write(unsigned long address, > > unsigned long offset, > > > > spin_unlock_irqrestore(&mdio___lock, flags); > > > > +#if 0 > > > > > > These *really* need to be controlled by a define, or Kconfig that > > controls > > a #define. > > > > Leaving #if 0 code around the tree is bad form. > > > > The #if 0 code was removed in a later patch in this series. Actually, > > this file was touched again several times in this series. This is also > > true of other patches with dead code removal issues. > > > > In some cases I tried to squash the cleanup together with a change, but > > I see other comments discouraging that approach. I think we are pretty > > stable at the tip, but it's pretty ugly how we got there. What is > > preferred? Squash later cleanup into this patch? (And other similar issues.) > > We can live with either. It all depends on how much of the development > history you want in the tree. Obviously once I've merged a patch series, > we don't want to squash exiting commits, but when you are sending a > new set of patches, the amount of squashing and history cleanup is in > your hands. It's the time to make it as clean (or dirty) as you want :) > > As long as the series is sane, and reasonably bisectable, I won't > quibble too much one way or the other.
Erm... well... with the exception that this work should be going upstream FIRST and then backported here. If it wouldn't be acceptable upstream, it isn't here either. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
