Netdev List
 help / color / mirror / Atom feed
* [PATCH 2/2] [PATCH] ax88179_178a: Add VID:DID for Samsung USB Ethernet Adapter
From: freddy @ 2013-10-22  7:32 UTC (permalink / raw)
  To: davem, linux-usb, linux-kernel, netdev, allan, louis; +Cc: Freddy Xin
In-Reply-To: <1382427131-2429-1-git-send-email-freddy@asix.com.tw>

From: Freddy Xin <freddy@asix.com.tw>

Add VID:DID for Samsung USB Ethernet Adapter.

Signed-off-by: Freddy Xin <freddy@asix.com.tw>
---
 drivers/net/usb/ax88179_178a.c |   19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 3bcd0d9..846cc19 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1406,6 +1406,19 @@ static const struct driver_info sitecom_info = {
 	.tx_fixup = ax88179_tx_fixup,
 };
 
+static const struct driver_info samsung_info = {
+	.description = "Samsung USB Ethernet Adapter",
+	.bind = ax88179_bind,
+	.unbind = ax88179_unbind,
+	.status = ax88179_status,
+	.link_reset = ax88179_link_reset,
+	.reset = ax88179_reset,
+	.stop = ax88179_stop,
+	.flags = FLAG_ETHER | FLAG_FRAMING_AX,
+	.rx_fixup = ax88179_rx_fixup,
+	.tx_fixup = ax88179_tx_fixup,
+};
+
 static const struct usb_device_id products[] = {
 {
 	/* ASIX AX88179 10/100/1000 */
@@ -1418,7 +1431,11 @@ static const struct usb_device_id products[] = {
 }, {
 	/* Sitecom USB 3.0 to Gigabit Adapter */
 	USB_DEVICE(0x0df6, 0x0072),
-	.driver_info = (unsigned long) &sitecom_info,
+	.driver_info = (unsigned long)&sitecom_info,
+}, {
+	/* Samsung USB Ethernet Adapter */
+	USB_DEVICE(0x04e8, 0xa100),
+	.driver_info = (unsigned long)&samsung_info,
 },
 	{ },
 };
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 1/2] [PATCH] ax88179_178a: Correct the RX error definition in RX header
From: freddy @ 2013-10-22  7:32 UTC (permalink / raw)
  To: davem, linux-usb, linux-kernel, netdev, allan, louis; +Cc: Freddy Xin

From: Freddy Xin <freddy@asix.com.tw>

Correct the definition of AX_RXHDR_CRC_ERR and
AX_RXHDR_DROP_ERR. They are BIT29 and BIT31 in pkt_hdr
seperately.

Signed-off-by: Freddy Xin <freddy@asix.com.tw>
---
 drivers/net/usb/ax88179_178a.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 3569293..3bcd0d9 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -36,8 +36,8 @@
 #define AX_RXHDR_L4_TYPE_TCP			16
 #define AX_RXHDR_L3CSUM_ERR			2
 #define AX_RXHDR_L4CSUM_ERR			1
-#define AX_RXHDR_CRC_ERR			((u32)BIT(31))
-#define AX_RXHDR_DROP_ERR			((u32)BIT(30))
+#define AX_RXHDR_CRC_ERR			((u32)BIT(29))
+#define AX_RXHDR_DROP_ERR			((u32)BIT(31))
 #define AX_ACCESS_MAC				0x01
 #define AX_ACCESS_PHY				0x02
 #define AX_ACCESS_EEPROM			0x04
-- 
1.7.10.4

^ permalink raw reply related

* RE: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
From: Ni, Xun @ 2013-10-22  7:15 UTC (permalink / raw)
  To: Daniel Borkmann, Daniel Wagner
  Cc: Eric W. Biederman, pablo@netfilter.org,
	netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
	Tejun Heo, cgroups@vger.kernel.org
In-Reply-To: <52654CE6.7030706@redhat.com>

Hello, Daniel:
   can all your examples block early before doing network operations? What's the whole netfilter universe? Can you give us more clear examples?

Thanks
On 10/21/2013 05:09 PM, Daniel Wagner wrote:
> On 10/19/2013 08:16 AM, Daniel Borkmann wrote:
>> On 10/19/2013 01:21 AM, Eric W. Biederman wrote:
>>
>>> I am coming to this late.  But two concrete suggestions.
>>>
>>> 1) process groups and sessions don't change as frequently as pids.
>>>
>>> 2) It is possible to put a set of processes in their own network
>>>     namespace and pipe just the packets you want those processes to
>>>     use into that network namespace.  Using an ingress queueing filter
>>>     makes that process very efficient even if you have to filter by port.
>>
>> Actually in our case we're filtering outgoing traffic, based on which 
>> local socket that originated from; so you wouldn't need all of that 
>> construct. Also, you wouldn't even need to have an a-prio knowledge 
>> of the application internals regarding their use of particular use of 
>> ports or protocols. I don't think that such a setup will have the 
>> same efficiency, ease of use, and power to distinguish the 
>> application the traffic came from in such a lightweight, protocol independent and easy way.
>
> Sorry for beeing late as well (and also stupid question)
>
> Couldn't you use something from the LSM? I mean you allow the 
> application to create the socket etc and then block later the traffic 
> originated from that socket. Wouldn't it make more sense to block 
> early?

I gave one simple example for blocking in the commit message, that's true, but it is not limited to that, meaning we can have much different scenarios/policies that netfilter allows us than just blocking, e.g. fine grained settings where applications are allowed to connect/send traffic to, application traffic marking/ conntracking, application-specific packet mangling, and so on, just think of the whole netfilter universe.
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] 3c59x: fix incorrect use of spin_lock_bh in interrupts
From: David Miller @ 2013-10-22  6:55 UTC (permalink / raw)
  To: mpatocka; +Cc: klassert, netdev
In-Reply-To: <alpine.LRH.2.02.1310211950360.5325@file01.intranet.prod.int.rdu2.redhat.com>

From: Mikulas Patocka <mpatocka@redhat.com>
Date: Mon, 21 Oct 2013 19:53:22 -0400 (EDT)

> The functions mdio_read and mdio_write may be called from interrupt
> context. Consequently, we must use spin_lock_irqsave instead of
> spin_lock_bh.
> 
> This patch should be backported to stable kernels.

vortex_down() does a lot of other things which are really dangerous
from an interrupt handler, such as del_timer_sync().

The real fix for this bug is to defer the vortex_error() work into
a workqueue, and thus process context, like every other driver does.

^ permalink raw reply

* Re: [PATCH net] netpoll: linearize skb before accessing its data
From: David Miller @ 2013-10-22  6:50 UTC (permalink / raw)
  To: antonio; +Cc: netdev
In-Reply-To: <20131022063714.GI1544@neomailbox.net>

From: Antonio Quartulli <antonio@meshcoding.com>
Date: Tue, 22 Oct 2013 08:37:14 +0200

> Ok I will do that. But I think this API change must go into
> net-next, right?  Otherwise we would break every existing user.

Too bad, it's a necessary API change to fix the bug, the users
will need to change too.

It's not our problem if they are out-of-tree and can't be fixed
in-situ.

^ permalink raw reply

* Re: [PATCH net] netpoll: linearize skb before accessing its data
From: Antonio Quartulli @ 2013-10-22  6:37 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20131022.022525.2068838304168924147.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Tue, Oct 22, 2013 at 02:25:25AM -0400, David Miller wrote:
> From: Antonio Quartulli <antonio@meshcoding.com>
> Date: Tue, 22 Oct 2013 08:06:35 +0200
> 
> > But rx_hook() does not receive any skb:
> > 
> > 609                 np->rx_hook(np, ntohs(uh->source),
> > 610                                (char *)(uh+1),
> > 611                                ulen - sizeof(struct udphdr));
> > 
> > it just receives a pointer to the data and can't do anything to make it linear.
> > (uh is a pointer to the udp header). Am I missing something?
> 
> Then this hook's API needs to be fixed, it's completely broken.
> 
> Make it pass the SKB and the appropriate offset (from skb->data) in
> bytes.
> 

Ok I will do that. But I think this API change must go into net-next, right?
Otherwise we would break every existing user.

What about resending this patch to net (after having removed the pskb_may_pull()
as pointed out by Eric) and then fixing the API in net-next?

-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH net] netpoll: linearize skb before accessing its data
From: David Miller @ 2013-10-22  6:25 UTC (permalink / raw)
  To: antonio; +Cc: netdev
In-Reply-To: <20131022060635.GF1544@neomailbox.net>

From: Antonio Quartulli <antonio@meshcoding.com>
Date: Tue, 22 Oct 2013 08:06:35 +0200

> But rx_hook() does not receive any skb:
> 
> 609                 np->rx_hook(np, ntohs(uh->source),
> 610                                (char *)(uh+1),
> 611                                ulen - sizeof(struct udphdr));
> 
> it just receives a pointer to the data and can't do anything to make it linear.
> (uh is a pointer to the udp header). Am I missing something?

Then this hook's API needs to be fixed, it's completely broken.

Make it pass the SKB and the appropriate offset (from skb->data) in
bytes.

^ permalink raw reply

* Re: [PATCH 3/3] net: ksz884x: use DEFINE_PCI_DEVICE_TABLE
From: David Miller @ 2013-10-22  6:19 UTC (permalink / raw)
  To: jg1.han; +Cc: netdev, buytenh
In-Reply-To: <001001ceced3$0bbdea20$2339be60$%han@samsung.com>

From: Jingoo Han <jg1.han@samsung.com>
Date: Tue, 22 Oct 2013 12:01:47 +0900

> This macro is used to create a struct pci_device_id array.
> 
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>

Applied.

^ permalink raw reply

* Re: [PATCH 2/3] net: tulip: use DEFINE_PCI_DEVICE_TABLE
From: David Miller @ 2013-10-22  6:19 UTC (permalink / raw)
  To: jg1.han; +Cc: netdev, grundler
In-Reply-To: <000f01ceced2$dde772b0$99b65810$%han@samsung.com>

From: Jingoo Han <jg1.han@samsung.com>
Date: Tue, 22 Oct 2013 12:00:30 +0900

> This macro is used to create a struct pci_device_id array.
> 
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>

Applied.

^ permalink raw reply

* Re: [PATCH 1/3] net: cxgb4vf: use DEFINE_PCI_DEVICE_TABLE
From: David Miller @ 2013-10-22  6:19 UTC (permalink / raw)
  To: jg1.han; +Cc: netdev, leedom
In-Reply-To: <000e01ceced2$a9e5d970$fdb18c50$%han@samsung.com>

From: Jingoo Han <jg1.han@samsung.com>
Date: Tue, 22 Oct 2013 11:59:02 +0900

> This macro is used to create a struct pci_device_id array.
> 
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] net: remove function sk_reset_txq()
From: David Miller @ 2013-10-22  6:18 UTC (permalink / raw)
  To: gamerh2o; +Cc: netdev, linux-kernel
In-Reply-To: <20131022041124.GA14122@will>

From: ZHAO Gang <gamerh2o@gmail.com>
Date: Tue, 22 Oct 2013 12:11:24 +0800

> What sk_reset_txq() does is just calls function sk_tx_queue_reset(),
> and sk_reset_txq() is used only in sock.h, by dst_negative_advice().
> Let dst_negative_advice() calls sk_tx_queue_reset() directly so we
> can remove unneeded sk_reset_txq().
> 
> Signed-off-by: ZHAO Gang <gamerh2o@gmail.com>

Still doesn't apply.

Email this patch to yourself, I bet the patch you receive won't
apply cleanly.  Likely your email client is corrupting the patch.

You've already eaten enough of my time as a maintainer submitting
a patch that won't even apply.  Absolutely do not resubmit this
patch until you can email the patch successfully to yourself
and successfuly apply the patch you receive in that email to
the current net-next tree.

^ permalink raw reply

* Re: [PATCH 1/1] [PATCH resubmit] ax88179_178a: Correct the RX error definition in RX header
From: David Miller @ 2013-10-22  6:15 UTC (permalink / raw)
  To: freddy; +Cc: linux-usb, linux-kernel, netdev, allan, louis
In-Reply-To: <1382406449-2041-1-git-send-email-freddy@asix.com.tw>


Submit these, not individually as single patches, but as a patch set,
the first one with subject "[PATCH 1/2]" and the second with
subject "[PATCH 2/2]"

You have to do this, because it is absolutely essentially to let
me know which patch gets applies first and which one gets applied
second.  The two patches are to the same file, so if you don't
tell me the order, they won't apply cleanly at all.

^ permalink raw reply

* Re: [PATCH 00/15] net: ethernet: remove unnecessary pci_set_drvdata() part 3
From: David Miller @ 2013-10-22  6:13 UTC (permalink / raw)
  To: jg1.han; +Cc: netdev
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

From: Jingoo Han <jg1.han@samsung.com>
Date: Tue, 22 Oct 2013 13:13:44 +0900

> Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound),
> the driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.

Series applied, thanks.

^ permalink raw reply

* Re: [PATCH net] netpoll: linearize skb before accessing its data
From: Antonio Quartulli @ 2013-10-22  6:06 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20131021.182319.625146263287554088.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On Mon, Oct 21, 2013 at 06:23:19PM -0400, David Miller wrote:
> From: Antonio Quartulli <antonio@meshcoding.com>
> Date: Mon, 21 Oct 2013 23:31:20 +0200
> 
> > __netpoll_rx() assumes that the data buffer of the received
> > skb is linear and then passes it to rx_hook().
> > However this is not true because the skb has not been
> > linearized yet.
> > 
> > This can cause rx_hook() to access non allocated memory
> > while parsing the received data.
> > 
> > Fix __netpoll_rx() by explicitly linearising the skb.
> > 
> > Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
> 
> It is rx_hook's obligation to access the SKB properly and not
> assume that the SKB is linear.  It is very expensive to
> linearize every SKB just for the sake of improperly implemented
> receive hooks.
> 
> In particular the rx hooks must make use of interface such
> as pskb_may_pull(), just like every other protocol does
> on packet input processing, to make sure the area they want
> to access is in the linear area.
> 

But rx_hook() does not receive any skb:

609                 np->rx_hook(np, ntohs(uh->source),
610                                (char *)(uh+1),
611                                ulen - sizeof(struct udphdr));

it just receives a pointer to the data and can't do anything to make it linear.
(uh is a pointer to the udp header). Am I missing something?


Regards,

-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH 01/15] net: pasemi: remove unnecessary pci_set_drvdata()
From: Olof Johansson @ 2013-10-22  6:07 UTC (permalink / raw)
  To: Jingoo Han; +Cc: David S. Miller, Network Development
In-Reply-To: <000701cecedd$3d7f24c0$b87d6e40$%han@samsung.com>

On Mon, Oct 21, 2013 at 9:14 PM, Jingoo Han <jg1.han@samsung.com> wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>

Acked-by: Olof Johansson <olof@lixom.net>

^ permalink raw reply

* [PATCH 15/15] net: cassini: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:21 UTC (permalink / raw)
  To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/sun/cassini.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c
index a72ecc4..b4d50d7 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -5168,7 +5168,6 @@ err_out_free_netdev:
 
 err_out_disable_pdev:
 	pci_disable_device(pdev);
-	pci_set_drvdata(pdev, NULL);
 	return -ENODEV;
 }
 
@@ -5206,7 +5205,6 @@ static void cas_remove_one(struct pci_dev *pdev)
 	free_netdev(dev);
 	pci_release_regions(pdev);
 	pci_disable_device(pdev);
-	pci_set_drvdata(pdev, NULL);
 }
 
 #ifdef CONFIG_PM
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 14/15] net: sunhme: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:20 UTC (permalink / raw)
  To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/sun/sunhme.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/sun/sunhme.c b/drivers/net/ethernet/sun/sunhme.c
index 99043b7..0dbf46f 100644
--- a/drivers/net/ethernet/sun/sunhme.c
+++ b/drivers/net/ethernet/sun/sunhme.c
@@ -3170,8 +3170,6 @@ static void happy_meal_pci_remove(struct pci_dev *pdev)
 	pci_release_regions(hp->happy_dev);
 
 	free_netdev(net_dev);
-
-	pci_set_drvdata(pdev, NULL);
 }
 
 static DEFINE_PCI_DEVICE_TABLE(happymeal_pci_ids) = {
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 13/15] net: stmmac: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:20 UTC (permalink / raw)
  To: 'David S. Miller'
  Cc: netdev, 'Jingoo Han', 'Giuseppe Cavallaro'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 023b7c2..644d80e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -138,7 +138,6 @@ static void stmmac_pci_remove(struct pci_dev *pdev)
 
 	stmmac_dvr_remove(ndev);
 
-	pci_set_drvdata(pdev, NULL);
 	pci_iounmap(pdev, priv->ioaddr);
 	pci_release_regions(pdev);
 	pci_disable_device(pdev);
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 12/15] net: smsc9420: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:19 UTC (permalink / raw)
  To: 'David S. Miller'
  Cc: netdev, 'Jingoo Han', 'Steve Glendinning'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/smsc/smsc9420.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/smsc/smsc9420.c b/drivers/net/ethernet/smsc/smsc9420.c
index 5f9e79f..e55e336 100644
--- a/drivers/net/ethernet/smsc/smsc9420.c
+++ b/drivers/net/ethernet/smsc/smsc9420.c
@@ -1707,8 +1707,6 @@ static void smsc9420_remove(struct pci_dev *pdev)
 	if (!dev)
 		return;
 
-	pci_set_drvdata(pdev, NULL);
-
 	pd = netdev_priv(dev);
 	unregister_netdev(dev);
 
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 11/15] net: epic100: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:19 UTC (permalink / raw)
  To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/smsc/epic100.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/smsc/epic100.c b/drivers/net/ethernet/smsc/epic100.c
index 03b256a..8c5c24a 100644
--- a/drivers/net/ethernet/smsc/epic100.c
+++ b/drivers/net/ethernet/smsc/epic100.c
@@ -1535,7 +1535,6 @@ static void epic_remove_one(struct pci_dev *pdev)
 	pci_release_regions(pdev);
 	free_netdev(dev);
 	pci_disable_device(pdev);
-	pci_set_drvdata(pdev, NULL);
 	/* pci_power_off(pdev, -1); */
 }
 
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 10/15] net: sis190: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:18 UTC (permalink / raw)
  To: 'David S. Miller'
  Cc: netdev, 'Jingoo Han', 'Francois Romieu'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/sis/sis190.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/sis/sis190.c b/drivers/net/ethernet/sis/sis190.c
index ee18e6f..acbbe48 100644
--- a/drivers/net/ethernet/sis/sis190.c
+++ b/drivers/net/ethernet/sis/sis190.c
@@ -1921,7 +1921,6 @@ static void sis190_remove_one(struct pci_dev *pdev)
 	cancel_work_sync(&tp->phy_task);
 	unregister_netdev(dev);
 	sis190_release_board(pdev);
-	pci_set_drvdata(pdev, NULL);
 }
 
 static struct pci_driver sis190_pci_driver = {
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 09/15] net: r8169: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:18 UTC (permalink / raw)
  To: 'David S. Miller'
  Cc: netdev, 'Jingoo Han',
	'Realtek linux nic maintainers',
	'Francois Romieu'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/realtek/r8169.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3397cee..7993875 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6811,7 +6811,6 @@ static void rtl_remove_one(struct pci_dev *pdev)
 
 	rtl_disable_msi(pdev, tp);
 	rtl8169_release_board(pdev, dev, tp->mmio_addr);
-	pci_set_drvdata(pdev, NULL);
 }
 
 static const struct net_device_ops rtl_netdev_ops = {
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 08/15] net: 8139too: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:17 UTC (permalink / raw)
  To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/realtek/8139too.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index 3ccedeb..50a9210 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -727,7 +727,6 @@ static void __rtl8139_cleanup_dev (struct net_device *dev)
 	pci_release_regions (pdev);
 
 	free_netdev(dev);
-	pci_set_drvdata (pdev, NULL);
 }
 
 
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 07/15] net: 8139cp: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:17 UTC (permalink / raw)
  To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/realtek/8139cp.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index d2e5919..f2a2128 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -2052,7 +2052,6 @@ static void cp_remove_one (struct pci_dev *pdev)
 	pci_release_regions(pdev);
 	pci_clear_mwi(pdev);
 	pci_disable_device(pdev);
-	pci_set_drvdata(pdev, NULL);
 	free_netdev(dev);
 }
 
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 06/15] net: r6040: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-22  4:17 UTC (permalink / raw)
  To: 'David S. Miller'
  Cc: netdev, 'Jingoo Han', 'Florian Fainelli'
In-Reply-To: <000601cecedd$1981e300$4c85a900$%han@samsung.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/rdc/r6040.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index e9dc849..1e49ec5 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -1231,7 +1231,6 @@ err_out_mdio:
 	mdiobus_free(lp->mii_bus);
 err_out_unmap:
 	netif_napi_del(&lp->napi);
-	pci_set_drvdata(pdev, NULL);
 	pci_iounmap(pdev, ioaddr);
 err_out_free_res:
 	pci_release_regions(pdev);
@@ -1257,7 +1256,6 @@ static void r6040_remove_one(struct pci_dev *pdev)
 	pci_release_regions(pdev);
 	free_netdev(dev);
 	pci_disable_device(pdev);
-	pci_set_drvdata(pdev, NULL);
 }
 
 
-- 
1.7.10.4

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox