[linux-yocto] [PATCH 48/94] drivers/net: Added debug code.

[Bruce Ashfield]

On 11/22/2013, 4:57 PM, Darren Hart wrote:
> 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.ashfield at windriver.com <mailto:bruce.ashfield at windriver.com>> wrote:
>>>
>>>      On 11/7/2013, 8:13 PM, Paul Butler wrote:
>>>
>>>          From: John Jacques <john.jacques at lsi.com
>>>          <mailto:john.jacques at lsi.com>>
>>>
>>>          Signed-off-by: John Jacques <john.jacques at lsi.com
>>>          <mailto:john.jacques at 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.

Agreed. I shouldn't be so implicit at times :)

Bruce

>