[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <80377ECBC5453840BA8C7155328B5377658B3F@RTITMBSV03.realtek.com.tw>
Date: Tue, 7 Oct 2014 05:45:16 +0000
From: Hau <hau@...ltek.com>
To: Francois Romieu <romieu@...zoreil.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
nic_swsd <nic_swsd@...ltek.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 net-next] r8169:add support for RTL8168EP
> -----Original Message-----
> From: Francois Romieu [mailto:romieu@...zoreil.com]
> Sent: Tuesday, October 07, 2014 6:13 AM
> To: Hau
> Cc: netdev@...r.kernel.org; nic_swsd; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v2 net-next] r8169:add support for RTL8168EP
>
> Hau <hau@...ltek.com> :
> [...]
> > Do you mean I should collect similar hardware parameters setting into
> > one function ? or I should set hardware parameters according to
> > hardware feature support version?
>
> static void r8168dp_ocp_write(...)
> [...]
>
> static void r8168ep_ocp_write(...)
> [...]
>
> static void ocp_write(...)
> {
> switch (...
> case ...
> r8168dp_ocp_write
>
> case ...
> r8168ep_ocp_write
> [...]
>
> static void rtl8168dp_driver_start(...)
> [...]
>
> static void rtl8168ep_driver_start(...)
> [...]
>
> etc.
>
> Nothing more. At some point the helpers themselves may turn into data
> struct members. Things don't need to be immediately right - if ever.
> However you really want to avoid unrelated changes in your patches:
> shuffling code and changing features at the same time hurts reviews, late
> regression hunts, backports, etc.
>
> --
> Ueimor
>
Thanks, I will do that on later patch.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists