From: Ben Dooks <ben.dooks@codethink•co.uk>
To: Ben Hutchings <ben.hutchings@codethink•co.uk>,
Geert Uytterhoeven <geert@linux-m68k•org>
Cc: linux-kernel@lists•codethink.co.uk,
Yoshihiro Kaneko <ykaneko0929@gmail•com>,
Sergei Shtylyov <sergei.shtylyov@cogentembedded•com>,
Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas•com>,
netdev@vger•kernel.org,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas•com>,
Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas•com>,
"David S. Miller" <davem@davemloft•net>
Subject: Re: [Linux-kernel] [net-next, 2/5] sh_eth: WARN on access to a register not implemented in a particular chip
Date: Mon, 09 Mar 2015 08:50:24 +0000 [thread overview]
Message-ID: <54FD5ED0.6070208@codethink.co.uk> (raw)
In-Reply-To: <1425561532.4288.34.camel@xylophone.i.decadent.org.uk>
On 05/03/15 13:18, Ben Hutchings wrote:
> On Thu, 2015-03-05 at 10:02 +0100, Geert Uytterhoeven wrote:
>> Replying to a patchwork mbox, as I noticed this is in net-next.
>>
>> On Thu, 26 Feb 2015, Ben Hutchings wrote:
>>> Currently we may silently read/write a register at offset 0. Change
>>> this to WARN and then ignore the write or read-back all-ones.
>>>
>>> Signed-off-by: Ben Hutchings <ben.hutchings@codethink•co.uk>
>>> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded•com>
>>
>> While this may be a good idea for debugging...
>>
>>> --- a/drivers/net/ethernet/renesas/sh_eth.h
>>> +++ b/drivers/net/ethernet/renesas/sh_eth.h
>>> @@ -543,19 +543,29 @@ static inline void sh_eth_soft_swap(char *src, int len)
>>> #endif
>>> }
>>>
>>> +#define SH_ETH_OFFSET_INVALID ((u16) ~0)
>>> +
>>> static inline void sh_eth_write(struct net_device *ndev, u32 data,
>>> int enum_index)
>>> {
>>> struct sh_eth_private *mdp = netdev_priv(ndev);
does de-referencing this each time make a difference? Looks like
it would have been easier to pass an "struct sh_eth_private" instead
of the "struct net_device *ndev"
>>> + u16 offset = mdp->reg_offset[enum_index];
>>> +
>>> + if (WARN_ON(offset == SH_ETH_OFFSET_INVALID))
>>> + return;
You could cange the mdp->reg_offset to an mdp->reg_pointer and make
any invalid registers a NULL. This would at-least make it fail on an
invalid access.
>> ... adding WARN_ON() to static inline functions increases code size a lot:
>>
>> $ size drivers/net/ethernet/renesas/sh_eth.o{.orig,}
>> text data bss dec hex filename
>> 23352 1136 0 24488 5fa8 drivers/net/ethernet/renesas/sh_eth.o.orig
>> 27225 1136 0 28361 6ec9 drivers/net/ethernet/renesas/sh_eth.o
>> $
>
> Time to un-inline it, maybe?
>
> Ben.
>
>
> _______________________________________________
> linux-kernel mailing list
> linux-kernel@lists•codethink.co.uk
> https://ducie-dc1.codethink.co.uk/cgi-bin/mailman/listinfo/linux-kernel
>
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
next prev parent reply other threads:[~2015-03-09 8:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 20:31 [PATCH net-next 0/5] sh_eth changes for net-next Ben Hutchings
2015-02-26 20:33 ` [PATCH net-next 1/5] sh_eth: Implement multicast statistic based on the RFS8 status bit Ben Hutchings
2015-02-26 20:34 ` [PATCH net-next 2/5] sh_eth: WARN on access to a register not implemented in a particular chip Ben Hutchings
2015-02-27 15:21 ` Sergei Shtylyov
2015-03-05 9:02 ` [net-next, " Geert Uytterhoeven
2015-03-05 13:18 ` Ben Hutchings
2015-03-09 8:50 ` Ben Dooks [this message]
2015-03-10 20:03 ` [Linux-kernel] " Sergei Shtylyov
2015-02-26 20:34 ` [PATCH net-next 3/5] sh_eth: Implement ethtool register dump operations Ben Hutchings
2015-02-26 20:34 ` [PATCH net-next 4/5] sh_eth: Optionally log RX and TX status for each completed descriptor Ben Hutchings
2015-02-26 20:35 ` [PATCH net-next 5/5] sh_eth: Mitigate lost statistics updates Ben Hutchings
2015-03-02 20:34 ` [PATCH net-next 0/5] sh_eth changes for net-next David Miller
2015-03-04 20:41 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54FD5ED0.6070208@codethink.co.uk \
--to=ben.dooks@codethink$(echo .)co.uk \
--cc=ben.hutchings@codethink$(echo .)co.uk \
--cc=davem@davemloft$(echo .)net \
--cc=geert@linux-m68k$(echo .)org \
--cc=linux-kernel@lists$(echo .)codethink.co.uk \
--cc=mitsuhiro.kimura.kc@renesas$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nobuhiro.iwamatsu.yj@renesas$(echo .)com \
--cc=sergei.shtylyov@cogentembedded$(echo .)com \
--cc=ykaneko0929@gmail$(echo .)com \
--cc=yoshihiro.shimoda.uh@renesas$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox