* RE: [PATCH net-next 6/7] r8169: add a new chip for RTL8106E
From: hayeswang @ 2013-04-02 2:59 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20130401222335.GC19335@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, April 02, 2013 6:24 AM
> To: Hayeswang
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 6/7] r8169: add a new chip for RTL8106E
>
> Hayes Wang <hayeswang@realtek.com> :
> [...]
> > - move rtl_set_rx_tx_desc_registers to avoid the tx/rx are enabled
> > before setting desc registers.
>
> This is a wholesale change for the 810x family.
>
> Please explain why issuing rtl_set_rx_tx_desc_registers before writing
> ChipCmd is not enough and feed it through a standalone commit.
>
According to the new initial flow of this new chip, the tx/rx would be enabled
in rtl_hw_start_8168g_2 function. And this function is run before
rtl_set_rx_tx_desc_registers. It would be a problem, so I move
rtl_set_rx_tx_desc_registers to make sure that the descriptor address would be
set before the tx/rx is enabled. It has no influence for the previous chips, and
I think the following new chips would base on the new flow.
Best Regards,
Hayes
^ permalink raw reply
* RE: [PATCH net-next 5/7] r8169: add a new chip for RTL8111G
From: hayeswang @ 2013-04-02 2:39 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20130401222235.GB19335@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, April 02, 2013 6:23 AM
> To: Hayeswang
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 5/7] r8169: add a new chip for RTL8111G
>
[..]
> There is close to zero added value for this stuff in the kernel.
> You may as well move it completely into the firmware.
Do you mean all of the phy settings? I have checked these settings with our hw
engineers. These are not firmware.
Best Regards,
Hayes
^ permalink raw reply
* RE: [PATCH net-next 2/7] r8169: Update PHY settings of RTL8111G
From: hayeswang @ 2013-04-02 2:19 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20130401222048.GA19335@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, April 02, 2013 6:21 AM
> To: Hayeswang
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 2/7] r8169: Update PHY settings
> of RTL8111G
>
> Hayes Wang <hayeswang@realtek.com> :
> > - Replace the current settings with rtl_writephy and rtl_readphy.
> > For the hardware, the settings are same with previous ones. This
> > make the setting method like the previous chips.
> > - Add new PHY settings.
>
> Would you mind spliting it in two ?
OK.
[...]
> > - if (r8168_phy_ocp_read(tp, 0xa466) & 0x0100)
> > - rtl_w1w0_phy_ocp(tp, 0xc41a, 0x0002, 0x0000);
> > - else
> > - rtl_w1w0_phy_ocp(tp, 0xbcc4, 0x0000, 0x0002);
> ^^^^^^
> This one was not right, was it ?
No, it was not right. It seems a mistake for copying and pasting.
^ permalink raw reply
* Private Assignment
From: info @ 2013-04-02 3:00 UTC (permalink / raw)
To: netdev
I need a Personal Representative to work in your area on part time and i will pay six hundred dollars per week. Kindly send your name & location for more info.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the wireless tree
From: Stephen Rothwell @ 2013-04-02 2:00 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Samuel Ortiz, John W. Linville
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/nfc/microread/mei.c between commit 9593b0b1179c ("NFC: microread:
Fix build failure due to a new MEI bus API") from the wireless tree and
commit 63cd353c34a0 ("NFC: microread: Fix MEI build failure") from the
net-next tree.
I fixed it up (using the wireless tree version) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [Patch net-next v1 3/4] vxlan: add ipv6 support
From: Cong Wang @ 2013-04-02 1:46 UTC (permalink / raw)
To: David Stevens; +Cc: David Miller, netdev, netdev-owner, stephen
In-Reply-To: <OF1E30BC31.571FBD44-ON85257B40.005F5AF2-85257B40.0063627F@us.ibm.com>
On Mon, 2013-04-01 at 14:05 -0400, David Stevens wrote:
> David Miller <davem@davemloft.net> wrote on 04/01/2013 01:02:23 PM:
>
> >
> > People avoid using sockaddr because it gets defined both in the kernel
> > exported userland headers and the native libc ones with no easy
> > protection between the two to avoid getting a double definition error.
> >
> > Once you start including kernel exported headers for things like these
> > network device specific interfaces, you potentially run into that issue.
> >
> > Therefore I'd rather the subsystem define their own unique type both
> > to avoid this double definition problem and to allow easy extention
> > later.
>
> I guess, but in this case, I'm not saying it's like a sockaddr
> with
> device-specific requirements. Rather, I'm saying it's exactly a sockaddr--
> it is either a sockaddr_in or a sockaddr_in6 and a family field to say
> which.
> As is, any user/kernel include file conflicts (in the "ip"
> command,
> presumably) are still present because he's using in6_addr, another
> structure
> both in user and kernel space.
> The primary multiple include issue here would be in the "ip"
> command,
> presumably, but sockaddrs in particular have to agree between user and
> kernel space already and both appear with "ip".
> This patch also has issues due to NOT copying other fields in the
> sockaddr_in6 structure (scope_id and port).
>
> Personally, I don't think it's too difficult to make correct code
> using sockaddr/sockaddr_in/sockaddr_in6 here, but even with a new type,
> the code within vxlan.c could (and I argue should) use something like:
>
> union {
> struct sockaddr_in vip_un_sin;
> struct sockaddr_in6 vip_un_sin6;
> struct sockaddr vip_un_sa;
> } vip_sun;
>
> #define vip_sa vip_sun.vip_un_sa
> #define vip_sin vip_sun.vip_un_sin
> #define vip_sin6 vip_sun.vip_un.sin6
>
> and then code like:
> switch (vip->vip_sa.sa_family) {
> case AF_INET:
> vip->vip_sin.sin_addr.s_addr = blah blah
> break;
> case AF_INET6:
> vip->vip_sin6.sin6_addr = blah blah
> break;
> ...
> }
>
> ...or whatever appropriate to the context and family.
Well, besides avoid redefining another type, what else could we gain by
using sockaddr_in6?
Look, we would have "vip->vip_sin.sin_addr.s_addr" instead of
"ipa->ip4", much longer than the current one...
So why defining a shorter and less complex struct matters?
^ permalink raw reply
* Re: [Patch net-next v1 3/4] vxlan: add ipv6 support
From: Cong Wang @ 2013-04-02 1:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, David S. Miller
In-Reply-To: <20130401131450.5d6bbc1e@nehalam.linuxnetplumber.net>
On Mon, 2013-04-01 at 13:14 -0700, Stephen Hemminger wrote:
> On Sun, 31 Mar 2013 13:43:44 +0800
> Cong Wang <amwang@redhat.com> wrote:
>
> > /* Need to drop RTNL to call multicast leave */
> > rtnl_unlock();
> > - lock_sock(sk);
> > - err = ip_mc_leave_group(sk, &mreq);
> > + if (vxlan->gaddr.proto == htons(ETH_P_IP)) {
> > + lock_sock(sk);
> > + err = ip_mc_leave_group(sk, &mreq);
> > + } else {
> > +#if IS_ENABLED(CONFIG_IPV6)
> > + lock_sock(sk);
> > + err = ipv6_sock_mc_drop(sk, vxlan->link, &vxlan->gaddr.ip6);
> > +#endif
> > + }
> > release_sock(sk);
>
> Since both v4 and v6 need socket locked why not?
>
> rtnl_unlock();
> lock_sock(sk);
> if (vxlan->gaddr.proto == htons(ETH_P_IP))
> err = ip_mc_leave_group(sk, &mreq);
> if IS_ENABLED(CONFIG_IPV6)
> else
> err = ipv6_sock_mc_drop(sk, vxlan->link, &vxlan->gaddr.ip6);
> #endif
>
> release_sock(sk);
Oh, of course, I missed that...
Thanks!
^ permalink raw reply
* [PATCH] ISDN:divert: beautify code: useless 'break', 'return (0)', additional comments.
From: Chen Gang @ 2013-04-02 1:37 UTC (permalink / raw)
To: Sergei Shtylyov, isdn, Jiri Slaby, 'Jiri Kosina', tilman
Cc: David Miller, netdev@vger.kernel.org >> netdev
In-Reply-To: <515993E1.5010508@cogentembedded.com>
delete useless 'break' after 'return'.
let 'return 0' instead of 'return (0)'
also give a comment for 'break' to let readers notice it.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/isdn/divert/isdn_divert.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/isdn/divert/isdn_divert.c b/drivers/isdn/divert/isdn_divert.c
index db432e6..50749a7 100644
--- a/drivers/isdn/divert/isdn_divert.c
+++ b/drivers/isdn/divert/isdn_divert.c
@@ -441,8 +441,7 @@ static int isdn_divert_icall(isdn_ctrl *ic)
switch (dv->rule.action) {
case DEFLECT_IGNORE:
- return (0);
- break;
+ return 0;
case DEFLECT_ALERT:
case DEFLECT_PROCEED:
@@ -510,10 +509,9 @@ static int isdn_divert_icall(isdn_ctrl *ic)
break;
default:
- return (0); /* ignore call */
- break;
+ return 0; /* ignore call */
} /* switch action */
- break;
+ break; /* will break the 'for' looping */
} /* scan_table */
if (cs) {
--
1.7.7.6
^ permalink raw reply related
* Re: oops in udpv6_sendmsg
From: Eric Dumazet @ 2013-04-02 1:23 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev
In-Reply-To: <1364582958.5113.49.camel@edumazet-glaptop>
On Fri, 2013-03-29 at 11:49 -0700, Eric Dumazet wrote:
> On Fri, 2013-03-29 at 14:40 -0400, Dave Jones wrote:
> > Just hit this on Linus' current tree.
> >
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000031
> > IP: [<ffffffff8166ca6b>] udpv6_sendmsg+0x34b/0xa90
> >
> > Looks like the last line of an inlined __ip6_dst_store() call. So line 1243 of net/ipv6/udp.c
> >
> > Dave
>
> Yes, I had the same problem on my lab machine yesterday and was working
> on it (Using a linux-3.3.8 code base)
>
> In my case, the invalid rt6i_node value was 0x66b579de
I am mystified by this problem, I could not reproduce it...
Hmm...
^ permalink raw reply
* Re: [PATCH 01/34] net: add skb_dst_set_noref_force
From: Simon Horman @ 2013-04-02 1:11 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: David Miller, lvs-devel, netdev, netfilter-devel, wensong, ja
In-Reply-To: <20130401224230.GA12356@localhost>
On Tue, Apr 02, 2013 at 12:42:30AM +0200, Pablo Neira Ayuso wrote:
> On Mon, Apr 01, 2013 at 12:57:33PM -0400, David Miller wrote:
> > From: Pablo Neira Ayuso <pablo@netfilter.org>
> > Date: Mon, 1 Apr 2013 14:06:44 +0200
> >
> > > Hi Simon,
> > >
> > > On Fri, Mar 29, 2013 at 01:11:18PM +0900, Simon Horman wrote:
> > >> From: Julian Anastasov <ja@ssi.bg>
> > >>
> > >> Rename skb_dst_set_noref to __skb_dst_set_noref and
> > >> add force flag as suggested by David Miller. The new wrapper
> > >> skb_dst_set_noref_force will force dst entries that are not
> > >> cached to be attached as skb dst without taking reference
> > >> as long as provided dst is reclaimed after RCU grace period.
> > >>
> > >> Signed-off-by: Julian Anastasov <ja@ssi.bg>
> > >> Signed-off by: Hans Schillstrom <hans@schillstrom.com>
> > >> Signed-off-by: Simon Horman <horms@verge.net.au>
> > >
> > > I think was acked by David, right?
> >
> > It was:
> >
> > Acked-by: David S. Miller <davem@davemloft.net>
>
> I have added this missing Acked-by to the patch. Simon, you'll have to
> rebase your tree, sorry.
Thanks. Sorry for the mix up.
^ permalink raw reply
* Private Assignment
From: info @ 2013-04-02 1:43 UTC (permalink / raw)
To: netdev
I need a Personal Representative to work in your area on part time and i will pay six hundred dollars per week. Kindly send your name & location for more info.
^ permalink raw reply
* Re: [PATCH] drivers/isdn/divert: beautify code, delete useless 'break'
From: Chen Gang @ 2013-04-02 0:44 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: isdn, Jiri Slaby, 'Jiri Kosina', tilman, David Miller,
netdev@vger.kernel.org >> netdev
In-Reply-To: <515993E1.5010508@cogentembedded.com>
On 2013年04月01日 22:04, Sergei Shtylyov wrote:
>
>> diff --git a/drivers/isdn/divert/isdn_divert.c
>> b/drivers/isdn/divert/isdn_divert.c
>> index db432e6..76d505e 100644
>> --- a/drivers/isdn/divert/isdn_divert.c
>> +++ b/drivers/isdn/divert/isdn_divert.c
>> @@ -442,7 +442,6 @@ static int isdn_divert_icall(isdn_ctrl *ic)
>> switch (dv->rule.action) {
>> case DEFLECT_IGNORE:
>> return (0);
>> - break;
>>
>> case DEFLECT_ALERT:
>> case DEFLECT_PROCEED:
>> @@ -511,7 +510,6 @@ static int isdn_divert_icall(isdn_ctrl *ic)
>>
>> default:
>> return (0); /* ignore call */
>> - break;
>
> You could have removed stupid () around 0, while at it.
oh, really, I should do it.
I will send patch v2 for it
thanks.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH] Fix IXP4xx coherent allocations
From: Ben Hutchings @ 2013-04-02 0:40 UTC (permalink / raw)
To: Krzysztof Halasa
Cc: Russell King - ARM Linux, linux-arm-kernel, netdev, David Miller,
linux-kernel, c.aeschlimann
In-Reply-To: <m3d2uexaxw.fsf@intrepid.localdomain>
On Mon, 2013-04-01 at 22:17 +0200, Krzysztof Halasa wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>
> > Right, so, the answer is - yes you are talking about platform devices,
> > and the reason that these aren't already set is because if you grep for
> > ixp4xx_eth or ixp4xx_hss in arch/arm/mach-ixp4xx, you'll notice that
> > _none_ of the device declarations set either of the DMA masks at all.
> > They don't even set the dev->dma_mask pointer. That is why the masks
> > are zero. For a device which does DMA, that is wrong.
>
> Well, that's new to me. Please tell me how it should be done.
> Should I simply add in platform code (on all platforms):
>
> +++ b/arch/arm/mach-ixp4xx/XXX.c
> @@ -380,10 +380,12 @@ static struct platform_device device_eth_tab[] = {
> .name = "ixp4xx_eth",
> .id = IXP4XX_ETH_NPEB,
> .dev.platform_data = eth_plat,
> + .dev.coherent_dma_mask = DMA_BIT_MASK(32),
> }, {
> .name = "ixp4xx_eth",
> .id = IXP4XX_ETH_NPEC,
> .dev.platform_data = eth_plat + 1,
> + .dev.coherent_dma_mask = DMA_BIT_MASK(32),
> }
> };
>
> This alone isn't going to work, the problem is coherent DMA mask in
> net_dev->dev and not in platform_device. So what do I do in the network
> drivers? Copy the masks from platform_device to the actual newly created
> net_dev->dev?
>
> Should I use the parent device (net_dev->dev.parent which is the
> platform_device) as the argument to the allocator? This would probably
> work though I'm not sure of its correctness.
[...]
Passing the parent device to DMA API functions seems to be the right
thing to do. It's what you would do in a PCI device driver.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 2/2] netfilter: TRACE: use IS_ENABLE to replace if defined
From: Pablo Neira Ayuso @ 2013-04-01 23:21 UTC (permalink / raw)
To: Gao feng; +Cc: netfilter-devel, netdev
In-Reply-To: <1363931322-2286-2-git-send-email-gaofeng@cn.fujitsu.com>
On Fri, Mar 22, 2013 at 01:48:42PM +0800, Gao feng wrote:
> Inder to reduce codes, Use IS_ENABLE to replace the
> if defined.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 01/34] net: add skb_dst_set_noref_force
From: Pablo Neira Ayuso @ 2013-04-01 22:42 UTC (permalink / raw)
To: David Miller; +Cc: horms, lvs-devel, netdev, netfilter-devel, wensong, ja
In-Reply-To: <20130401.125733.1045325402548119287.davem@davemloft.net>
On Mon, Apr 01, 2013 at 12:57:33PM -0400, David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Mon, 1 Apr 2013 14:06:44 +0200
>
> > Hi Simon,
> >
> > On Fri, Mar 29, 2013 at 01:11:18PM +0900, Simon Horman wrote:
> >> From: Julian Anastasov <ja@ssi.bg>
> >>
> >> Rename skb_dst_set_noref to __skb_dst_set_noref and
> >> add force flag as suggested by David Miller. The new wrapper
> >> skb_dst_set_noref_force will force dst entries that are not
> >> cached to be attached as skb dst without taking reference
> >> as long as provided dst is reclaimed after RCU grace period.
> >>
> >> Signed-off-by: Julian Anastasov <ja@ssi.bg>
> >> Signed-off by: Hans Schillstrom <hans@schillstrom.com>
> >> Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > I think was acked by David, right?
>
> It was:
>
> Acked-by: David S. Miller <davem@davemloft.net>
I have added this missing Acked-by to the patch. Simon, you'll have to
rebase your tree, sorry.
^ permalink raw reply
* Re: [GIT PULL nf-next] IPVS optimisations for v3.10
From: Pablo Neira Ayuso @ 2013-04-01 22:41 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
In-Reply-To: <1364530311-11512-1-git-send-email-horms@verge.net.au>
On Fri, Mar 29, 2013 at 01:11:17PM +0900, Simon Horman wrote:
> Hi Pablo,
>
> The following changes since commit e5c5d22e8dcf7c2d430336cbf8e180bd38e8daf1:
>
> net: add ETH_P_802_3_MIN (2013-03-28 01:20:42 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git tags/ipvs2-for-v3.10
>
> for you to fetch changes up to e0566a7cef2f1afca4aa98244224fb9ca6ded08e:
>
> ipvs: do not disable bh for long time (2013-03-29 12:59:02 +0900)
Pulled, thanks Simon.
^ permalink raw reply
* Re: [PATCH] net-sysfs: make flags symmetrical
From: Ben Greear @ 2013-04-01 22:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20130401150407.0d689980@nehalam.linuxnetplumber.net>
On 04/01/2013 03:04 PM, Stephen Hemminger wrote:
> On Mon, 01 Apr 2013 13:16:43 -0700
> Ben Greear <greearb@candelatech.com> wrote:
>
>> On 04/01/2013 11:53 AM, Stephen Hemminger wrote:
>>> The flags reported by sysfs are the raw kernel flags, not the version
>>> exported to user space. This leads to the unsymmetrical behaviour that
>>> read != write. An example of this is when a device is part of a
>>> bridge. The PROMISC flag returned from sysfs will not be the same as
>>> other API's.
>>>
>>> The reason this patch deserves wider discussion is someone might be
>>> depending on sysfs to read raw kernel flags.
>>
>> I am depending on this feature. There is no other way I know
>> of to determine if an interface is actually currently acting
>> PROMISC or not.
>>
>> Please don't 'fix' this.
>>
>> Thanks,
>> Ben
>>
>
> The real problem is there isn't a netlink attribute that encodes
> the real flags (there should be), and when device changes state a notification
> should be sent.
Ok, that sounds great to me...but plz don't remove the work-around
in sysfs in the meantime :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next 7/7] r8169: fix could not dump registers
From: Francois Romieu @ 2013-04-01 22:24 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1364824539-4156-7-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> For new version of Fedora and Ubuntu, we see all 0xff when dumping
> the hw regs through ethtool. Using a loop to read registers could
> fix it.
If it fixes a problem which lives outside of net-next, it should target
"net", not "net-next".
"new version" does not help when a commit log can be read at any time
and/or when people try to identify patches for -stable branches. You do
not say which kernel / chipsets combination are known to exhibit the
problem.
Fundamentally, nobody can tell from the description if it is a kernel
or hardware problem nor why things work better after the change.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 6/7] r8169: add a new chip for RTL8106E
From: Francois Romieu @ 2013-04-01 22:23 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1364824539-4156-6-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
[...]
> - move rtl_set_rx_tx_desc_registers to avoid the tx/rx are enabled
> before setting desc registers.
This is a wholesale change for the 810x family.
Please explain why issuing rtl_set_rx_tx_desc_registers before writing
ChipCmd is not enough and feed it through a standalone commit.
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> drivers/net/ethernet/realtek/r8169.c | 25 +++++++++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 8d41508..876e088 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -49,6 +49,7 @@
> #define FIRMWARE_8106E_1 "rtl_nic/rtl8106e-1.fw"
> #define FIRMWARE_8168G_2 "rtl_nic/rtl8168g-2.fw"
> #define FIRMWARE_8168G_3 "rtl_nic/rtl8168g-3.fw"
> +#define FIRMWARE_8106E_2 "rtl_nic/rtl8106e-2.fw"
I'd rather keep those sorted.
[...]
> @@ -824,6 +829,7 @@ MODULE_FIRMWARE(FIRMWARE_8411_1);
> MODULE_FIRMWARE(FIRMWARE_8106E_1);
> MODULE_FIRMWARE(FIRMWARE_8168G_2);
> MODULE_FIRMWARE(FIRMWARE_8168G_3);
> +MODULE_FIRMWARE(FIRMWARE_8106E_2);
Same thing as above.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 5/7] r8169: add a new chip for RTL8111G
From: Francois Romieu @ 2013-04-01 22:22 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1364824539-4156-5-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 0211836..8d41508 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> +static void rtl8168g_2_hw_phy_config(struct rtl8169_private *tp)
> +{
> + rtl_apply_firmware(tp);
> +
> + rtl_writephy(tp, 0x1f, 0x0bcc);
> + rtl_w1w0_phy(tp, 0x14, 0x0000, 0x0100);
> + rtl_writephy(tp, 0x1f, 0x0a44);
> + rtl_w1w0_phy(tp, 0x11, 0x00c0, 0x0000);
> + rtl_writephy(tp, 0x1f, 0x0a43);
> + rtl_writephy(tp, 0x13, 0x8084);
> + rtl_w1w0_phy(tp, 0x14, 0x0000, 0x6000);
> + rtl_w1w0_phy(tp, 0x10, 0x1003, 0x0000);
> +
> + /* Enable UC LPF tune function */
> + rtl_writephy(tp, 0x1f, 0x0a43);
> + rtl_writephy(tp, 0x13, 0x8012);
> + rtl_w1w0_phy(tp, 0x14, 0x8000, 0x0000);
> +
> + rtl_writephy(tp, 0x1f, 0x0bce);
> + rtl_writephy(tp, 0x12, 0x8860);
> +
> + /* Channel Estimation: master */
> + rtl_writephy(tp, 0x1f, 0x0a43);
> + rtl_writephy(tp, 0x13, 0x80f3);
> + rtl_w1w0_phy(tp, 0x14, 0x8b00, 0x7400);
> + rtl_writephy(tp, 0x13, 0x80f0);
> + rtl_w1w0_phy(tp, 0x14, 0x3a00, 0xc500);
> + rtl_writephy(tp, 0x13, 0x80ef);
> + rtl_w1w0_phy(tp, 0x14, 0x0500, 0xfa00);
> + rtl_writephy(tp, 0x13, 0x80f6);
> + rtl_w1w0_phy(tp, 0x14, 0x6e00, 0x9100);
> + rtl_writephy(tp, 0x13, 0x80ec);
> + rtl_w1w0_phy(tp, 0x14, 0x6800, 0x9700);
> + rtl_writephy(tp, 0x13, 0x80ed);
> + rtl_w1w0_phy(tp, 0x14, 0x7c00, 0x8300);
> + rtl_writephy(tp, 0x13, 0x80f2);
> + rtl_w1w0_phy(tp, 0x14, 0xf400, 0x0b00);
> + rtl_writephy(tp, 0x13, 0x80f4);
> + rtl_w1w0_phy(tp, 0x14, 0x8500, 0x7a00);
> +
> + /* Channel Estimation: slave */
> + rtl_writephy(tp, 0x1f, 0x0a43);
> + rtl_writephy(tp, 0x13, 0x8110);
> + rtl_w1w0_phy(tp, 0x14, 0xa800, 0x5700);
> + rtl_writephy(tp, 0x13, 0x810f);
> + rtl_w1w0_phy(tp, 0x14, 0x1d00, 0xe200);
> + rtl_writephy(tp, 0x13, 0x8111);
> + rtl_w1w0_phy(tp, 0x14, 0xf500, 0x0a00);
> + rtl_writephy(tp, 0x13, 0x8113);
> + rtl_w1w0_phy(tp, 0x14, 0x6100, 0x9e00);
> + rtl_writephy(tp, 0x13, 0x8115);
> + rtl_w1w0_phy(tp, 0x14, 0x9200, 0x6d00);
> + rtl_writephy(tp, 0x13, 0x810e);
> + rtl_w1w0_phy(tp, 0x14, 0x0400, 0xfb00);
> + rtl_writephy(tp, 0x13, 0x810c);
> + rtl_w1w0_phy(tp, 0x14, 0x7c00, 0x8300);
> + rtl_writephy(tp, 0x13, 0x810b);
> + rtl_w1w0_phy(tp, 0x14, 0x5a00, 0xa500);
> +
> + /* Channel Estimation: 100 */
> + rtl_writephy(tp, 0x1f, 0x0a43);
> + rtl_writephy(tp, 0x13, 0x80d1);
> + rtl_w1w0_phy(tp, 0x14, 0xff00, 0x0000);
> + rtl_writephy(tp, 0x13, 0x80cd);
> + rtl_w1w0_phy(tp, 0x14, 0x9e00, 0x6100);
> + rtl_writephy(tp, 0x13, 0x80d3);
> + rtl_w1w0_phy(tp, 0x14, 0x0e00, 0xf100);
> + rtl_writephy(tp, 0x13, 0x80d5);
> + rtl_w1w0_phy(tp, 0x14, 0xca00, 0x3500);
> + rtl_writephy(tp, 0x13, 0x80d7);
> + rtl_w1w0_phy(tp, 0x14, 0x8400, 0x7b00);
> +
> + rtl_writephy(tp, 0x1f, 0x0000);
There is close to zero added value for this stuff in the kernel.
You may as well move it completely into the firmware.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 2/7] r8169: Update PHY settings of RTL8111G
From: Francois Romieu @ 2013-04-01 22:20 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1364824539-4156-2-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> - Replace the current settings with rtl_writephy and rtl_readphy.
> For the hardware, the settings are same with previous ones. This
> make the setting method like the previous chips.
> - Add new PHY settings.
Would you mind spliting it in two ?
On closer inspection the settings do not look the same.
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> drivers/net/ethernet/realtek/r8169.c | 72 +++++++++++++++++++++++++-----------
> 1 file changed, 51 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index d36aa76..b8b59a9 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> @@ -3370,23 +3362,61 @@ static void rtl8168g_1_hw_phy_config(struct rtl8169_private *tp)
> {
> rtl_apply_firmware(tp);
>
> - if (r8168_phy_ocp_read(tp, 0xa460) & 0x0100)
> - rtl_w1w0_phy_ocp(tp, 0xbcc4, 0x0000, 0x8000);
> - else
> - rtl_w1w0_phy_ocp(tp, 0xbcc4, 0x8000, 0x0000);
> + rtl_writephy(tp, 0x1f, 0x0a46);
> + if (rtl_readphy(tp, 0x10) & 0x0100) {
> + rtl_writephy(tp, 0x1f, 0x0bcc);
> + rtl_w1w0_phy(tp, 0x12, 0x0000, 0x8000);
> + } else {
> + rtl_writephy(tp, 0x1f, 0x0bcc);
> + rtl_w1w0_phy(tp, 0x12, 0x8000, 0x0000);
> + }
>
> - if (r8168_phy_ocp_read(tp, 0xa466) & 0x0100)
> - rtl_w1w0_phy_ocp(tp, 0xc41a, 0x0002, 0x0000);
> - else
> - rtl_w1w0_phy_ocp(tp, 0xbcc4, 0x0000, 0x0002);
^^^^^^
This one was not right, was it ?
> + rtl_writephy(tp, 0x1f, 0x0a46);
> + if (rtl_readphy(tp, 0x13) & 0x0100) {
> + rtl_writephy(tp, 0x1f, 0x0c41);
> + rtl_w1w0_phy(tp, 0x15, 0x0002, 0x0000);
> + } else {
> + rtl_writephy(tp, 0x1f, 0x0c41);
> + rtl_w1w0_phy(tp, 0x15, 0x0000, 0x0002);
> + }
--
Ueimor
^ permalink raw reply
* Re: [PATCH] net-sysfs: make flags symmetrical
From: Stephen Hemminger @ 2013-04-01 22:04 UTC (permalink / raw)
To: Ben Greear; +Cc: David Miller, netdev
In-Reply-To: <5159EB2B.7070504@candelatech.com>
On Mon, 01 Apr 2013 13:16:43 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 04/01/2013 11:53 AM, Stephen Hemminger wrote:
> > The flags reported by sysfs are the raw kernel flags, not the version
> > exported to user space. This leads to the unsymmetrical behaviour that
> > read != write. An example of this is when a device is part of a
> > bridge. The PROMISC flag returned from sysfs will not be the same as
> > other API's.
> >
> > The reason this patch deserves wider discussion is someone might be
> > depending on sysfs to read raw kernel flags.
>
> I am depending on this feature. There is no other way I know
> of to determine if an interface is actually currently acting
> PROMISC or not.
>
> Please don't 'fix' this.
>
> Thanks,
> Ben
>
The real problem is there isn't a netlink attribute that encodes
the real flags (there should be), and when device changes state a notification
should be sent.
^ permalink raw reply
* Re: [PATCH] net-sysfs: make flags symmetrical
From: Ben Greear @ 2013-04-01 21:32 UTC (permalink / raw)
To: David Miller; +Cc: stephen, netdev
In-Reply-To: <20130401.171858.2177408540657698898.davem@davemloft.net>
On 04/01/2013 02:18 PM, David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Mon, 01 Apr 2013 13:16:43 -0700
>
>> I am depending on this feature. There is no other way I know
>> of to determine if an interface is actually currently acting
>> PROMISC or not.
>
> Netlink interface dump, SIOGIFCONF, etc. should provide this
> information in one form or another.
From looking elsewhere in my code, I think you are right, at least
about netlink.
The IFLA_PROMISCUITY field seems to give good results, but if you try
to parse the ifinfomsg->ifi_flags method, it may lie to you
and tell you the netdev is not PROMISSC when it really is PROMISC.
I haven't tried SIOGIFCONF...
Either way, I'd prefer the sysfs flags stay as is...while I have
the netlink interface coded up in my app, it is not exactly light
programming and other tools may find it much easier to use
the sysfs flags. And, since I've been using the sysfs flags
to double-check netlink in some cases, I'll have to add yet more
hacks if this compatibility is broken in newer kernels...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] net-sysfs: make flags symmetrical
From: David Miller @ 2013-04-01 21:18 UTC (permalink / raw)
To: greearb; +Cc: stephen, netdev
In-Reply-To: <5159EB2B.7070504@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Mon, 01 Apr 2013 13:16:43 -0700
> I am depending on this feature. There is no other way I know
> of to determine if an interface is actually currently acting
> PROMISC or not.
Netlink interface dump, SIOGIFCONF, etc. should provide this
information in one form or another.
^ permalink raw reply
* Re: [PATCH] Fix IXP4xx coherent allocations
From: Krzysztof Halasa @ 2013-04-01 20:17 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Ben Hutchings, linux-arm-kernel, netdev, David Miller,
linux-kernel, c.aeschlimann
In-Reply-To: <20130330153135.GC17995@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> Right, so, the answer is - yes you are talking about platform devices,
> and the reason that these aren't already set is because if you grep for
> ixp4xx_eth or ixp4xx_hss in arch/arm/mach-ixp4xx, you'll notice that
> _none_ of the device declarations set either of the DMA masks at all.
> They don't even set the dev->dma_mask pointer. That is why the masks
> are zero. For a device which does DMA, that is wrong.
Well, that's new to me. Please tell me how it should be done.
Should I simply add in platform code (on all platforms):
+++ b/arch/arm/mach-ixp4xx/XXX.c
@@ -380,10 +380,12 @@ static struct platform_device device_eth_tab[] = {
.name = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEB,
.dev.platform_data = eth_plat,
+ .dev.coherent_dma_mask = DMA_BIT_MASK(32),
}, {
.name = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEC,
.dev.platform_data = eth_plat + 1,
+ .dev.coherent_dma_mask = DMA_BIT_MASK(32),
}
};
This alone isn't going to work, the problem is coherent DMA mask in
net_dev->dev and not in platform_device. So what do I do in the network
drivers? Copy the masks from platform_device to the actual newly created
net_dev->dev?
Should I use the parent device (net_dev->dev.parent which is the
platform_device) as the argument to the allocator? This would probably
work though I'm not sure of its correctness.
BTW the platform code shouldn't IMHO need to declare the masks as they
aren't platform-specific. They are driver-specific (defined by CPU
design) and setting them in the driver seems clean to me (unlike the
platform code).
Several other device drivers simply set their masks directly. Is it the
recommended way?
> If you look at the PCI code, it pre-initializes the DMA mask to be 4GiB:
> drivers/pci/probe.c: dev->dev.coherent_dma_mask = 0xffffffffull;
>
> And that is what is missing from the IXP4xx platform code.
>
> However, avoiding the call to dma_set_coherent_mask() from within the
> driver also seems to be questionable as it bypasses the "check if the
> mask is possible" part of the DMA API.
I thought about this for a second but the situation is the mask
is guaranteed to be valid (these are on-chip devices).
--
Krzysztof Halasa
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox