* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Konrad Rzeszutek Wilk @ 2012-02-16 19:48 UTC (permalink / raw)
To: Andrew Jones; +Cc: jeremy, xen-devel, konrad.wilk, virtualization
In-Reply-To: <1329394629-10299-1-git-send-email-drjones@redhat.com>
On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> We just reported to xenbus that we can't close yet, because
> blkfront is still in use. So we shouldn't then immediately
> state that we are closing.
What happens if the user uses --force to unplug the device?
Will that still work?
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> drivers/block/xen-blkfront.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5d45688..b53cae4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
> if (bdev->bd_openers) {
> xenbus_dev_error(xbdev, -EBUSY,
> "Device in use; refusing to close");
> - xenbus_switch_state(xbdev, XenbusStateClosing);
> } else {
> xlvbd_release_gendisk(info);
> xenbus_frontend_closed(xbdev);
> --
> 1.7.7.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't put bdev right after getting it
From: Konrad Rzeszutek Wilk @ 2012-02-16 19:44 UTC (permalink / raw)
To: Andrew Jones; +Cc: jeremy, xen-devel, konrad.wilk, virtualization
In-Reply-To: <1329394585-10129-1-git-send-email-drjones@redhat.com>
On Thu, Feb 16, 2012 at 01:16:25PM +0100, Andrew Jones wrote:
> We should hang onto bdev until we're done with it.
Looks ok. Is there a BZ that sparked this? Thanks.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> drivers/block/xen-blkfront.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..5d45688 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
> mutex_lock(&blkfront_mutex);
>
> bdev = bdget_disk(disk, 0);
> - bdput(bdev);
>
> if (bdev->bd_openers)
> goto out;
> @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
> }
>
> out:
> + bdput(bdev);
> mutex_unlock(&blkfront_mutex);
> return 0;
> }
> --
> 1.7.7.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Andrew Jones @ 2012-02-16 17:33 UTC (permalink / raw)
To: xen-devel; +Cc: jeremy, konrad wilk, virtualization
In-Reply-To: <1329394629-10299-1-git-send-email-drjones@redhat.com>
----- Original Message -----
> We just reported to xenbus that we can't close yet, because
> blkfront is still in use. So we shouldn't then immediately
> state that we are closing.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> drivers/block/xen-blkfront.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c
> b/drivers/block/xen-blkfront.c
> index 5d45688..b53cae4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
> if (bdev->bd_openers) {
> xenbus_dev_error(xbdev, -EBUSY,
> "Device in use; refusing to close");
> - xenbus_switch_state(xbdev, XenbusStateClosing);
> } else {
> xlvbd_release_gendisk(info);
> xenbus_frontend_closed(xbdev);
> --
> 1.7.7.5
>
Hmm, I should maybe self-nack this. The bug that led me to writing
it is likely only with older tooling, such as RHEL5's. The problem
was if you attempted to detach a mounted disk twice, then the second
time it would succeed. The guest had flipped to Closing on the first
try, and thus didn't issue an error to xenbus on the second. I see now
in libxl__initiate_device_remove() that it bails out if state != 4,
so that tooling shouldn't have this issue.
The reason I only say maybe self-nack though, is because this state
change seemed to be thrown in with another fix[1]. I'm not sure if
the new behavior on legacy hosts was considered or not. If not, then
we can consider it now. Do we want to have deferred asynch detaches
over protecting the guest from multiple detach calls on legacy hosts?
Drew
[1] b70f5fa blkfront: Lock blkfront_info when closing
^ permalink raw reply
* [PATCH] blkfront: don't change to closing if we're busy
From: Andrew Jones @ 2012-02-16 12:17 UTC (permalink / raw)
To: xen-devel; +Cc: jeremy, virtualization, konrad.wilk
We just reported to xenbus that we can't close yet, because
blkfront is still in use. So we shouldn't then immediately
state that we are closing.
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
drivers/block/xen-blkfront.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5d45688..b53cae4 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
if (bdev->bd_openers) {
xenbus_dev_error(xbdev, -EBUSY,
"Device in use; refusing to close");
- xenbus_switch_state(xbdev, XenbusStateClosing);
} else {
xlvbd_release_gendisk(info);
xenbus_frontend_closed(xbdev);
--
1.7.7.5
^ permalink raw reply related
* [PATCH] blkfront: don't put bdev right after getting it
From: Andrew Jones @ 2012-02-16 12:16 UTC (permalink / raw)
To: xen-devel; +Cc: jeremy, virtualization, konrad.wilk
We should hang onto bdev until we're done with it.
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
drivers/block/xen-blkfront.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..5d45688 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
mutex_lock(&blkfront_mutex);
bdev = bdget_disk(disk, 0);
- bdput(bdev);
if (bdev->bd_openers)
goto out;
@@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
}
out:
+ bdput(bdev);
mutex_unlock(&blkfront_mutex);
return 0;
}
--
1.7.7.5
^ permalink raw reply related
* Re: [PATCH v2 1/2] net: replace random_ether_addr() with eth_hw_addr_random()
From: David Miller @ 2012-02-15 20:34 UTC (permalink / raw)
To: danny.kukawka
Cc: mst, venza, yoshfuji, netdev, linux-usb, dkukawka, linux-kernel,
nicolas.ferre, rl, hsweeten, gregkh, peppe.cavallaro,
steve.glendinning, kuznet, jmorris, virtualization, florian, khc
In-Reply-To: <1329324340-13461-2-git-send-email-danny.kukawka@bisect.de>
From: Danny Kukawka <danny.kukawka@bisect.de>
Date: Wed, 15 Feb 2012 17:45:39 +0100
> Replace usage of random_ether_addr() with eth_hw_addr_random()
> to set addr_assign_type correctly to NET_ADDR_RANDOM.
>
> Change the trivial cases.
>
> v2: adapt to renamed eth_hw_addr_random()
>
> Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Applied.
^ permalink raw reply
* [RESEND][PATCH v2 0/2] Part 2: handle addr_assign_type for random addresses
From: Danny Kukawka @ 2012-02-15 17:08 UTC (permalink / raw)
To: David S. Miller
Cc: Michael S. Tsirkin, Nicolas Ferre, Eilon Greenstein, Roger Luethi,
Daniele Venzano, Stephen Hemminger, dev, bridge, Danny Kukawka,
James Morris, Alexey Kuznetsov, Jesse Gross, Chris Metcalf,
Giuseppe Cavallaro, virtualization, Florian Fainelli, Jiri Pirko,
Hideaki YOSHIFUJI, Greg Kroah-Hartman, linux-usb, linux-kernel,
Hartley Sweeten, netdev, Steve Glendinning <steve.glendin>
The second part of my patch series to fix the handling of
addr_assign_type for random MAC addresses. This contains the
trival changes from random_ether_addr() to new
eth_hw_addr_random() and code to reset the state to
NET_ADDR_PERM as soon as the MAC get changed via
.ndo_set_mac_address where eth_mac_addr wasn't used.
Resend due to send with too long recipients list. Sorry!
Thanks to Joe Perches for the hint.
Danny Kukawka (2):
net: replace random_ether_addr() with eth_hw_addr_random()
net: use eth_hw_addr_random() and reset addr_assign_type
drivers/net/dummy.c | 3 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
drivers/net/ethernet/cadence/macb.c | 2 +-
drivers/net/ethernet/calxeda/xgmac.c | 3 ++-
drivers/net/ethernet/cirrus/ep93xx_eth.c | 2 +-
drivers/net/ethernet/davicom/dm9000.c | 2 +-
drivers/net/ethernet/dnet.c | 2 +-
drivers/net/ethernet/faraday/ftgmac100.c | 2 +-
drivers/net/ethernet/faraday/ftmac100.c | 2 +-
drivers/net/ethernet/marvell/pxa168_eth.c | 3 ++-
drivers/net/ethernet/micrel/ks8842.c | 3 ++-
drivers/net/ethernet/micrel/ks8851.c | 3 ++-
drivers/net/ethernet/micrel/ks8851_mll.c | 1 +
drivers/net/ethernet/microchip/enc28j60.c | 3 ++-
drivers/net/ethernet/mipsnet.c | 2 +-
drivers/net/ethernet/natsemi/macsonic.c | 2 +-
drivers/net/ethernet/nvidia/forcedeth.c | 3 ++-
drivers/net/ethernet/rdc/r6040.c | 2 +-
drivers/net/ethernet/sis/sis900.c | 2 +-
drivers/net/ethernet/smsc/smsc911x.c | 3 ++-
drivers/net/ethernet/smsc/smsc9420.c | 5 ++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
drivers/net/ethernet/tile/tilepro.c | 3 ++-
drivers/net/ethernet/toshiba/tc35815.c | 2 +-
drivers/net/ethernet/via/via-rhine.c | 2 +-
drivers/net/ifb.c | 2 +-
drivers/net/macvlan.c | 3 ++-
drivers/net/team/team.c | 3 ++-
drivers/net/tun.c | 2 +-
drivers/net/usb/smsc75xx.c | 2 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/veth.c | 4 ++--
drivers/net/virtio_net.c | 2 +-
drivers/net/wan/hdlc_fr.c | 2 +-
drivers/net/wan/hdlc_raw_eth.c | 2 +-
net/bridge/br_device.c | 3 ++-
net/ipv4/ip_gre.c | 2 +-
net/l2tp/l2tp_eth.c | 2 +-
net/openvswitch/vport-internal_dev.c | 3 ++-
40 files changed, 55 insertions(+), 41 deletions(-)
--
1.7.8.3
^ permalink raw reply
* [PATCH v2 1/2] net: replace random_ether_addr() with eth_hw_addr_random()
From: Danny Kukawka @ 2012-02-15 16:45 UTC (permalink / raw)
To: David S. Miller
Cc: Michael S. Tsirkin, Daniele Venzano, Hideaki YOSHIFUJI, netdev,
linux-usb, Danny Kukawka, linux-kernel, Nicolas Ferre,
Roger Luethi, Hartley Sweeten, Greg Kroah-Hartman,
Giuseppe Cavallaro, Steve Glendinning, Alexey Kuznetsov,
James Morris, virtualization, Florian Fainelli, Krzysztof Halasa
In-Reply-To: <1329324340-13461-1-git-send-email-danny.kukawka@bisect.de>
Replace usage of random_ether_addr() with eth_hw_addr_random()
to set addr_assign_type correctly to NET_ADDR_RANDOM.
Change the trivial cases.
v2: adapt to renamed eth_hw_addr_random()
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
---
drivers/net/ethernet/cadence/macb.c | 2 +-
drivers/net/ethernet/cirrus/ep93xx_eth.c | 2 +-
drivers/net/ethernet/davicom/dm9000.c | 2 +-
drivers/net/ethernet/dnet.c | 2 +-
drivers/net/ethernet/faraday/ftgmac100.c | 2 +-
drivers/net/ethernet/faraday/ftmac100.c | 2 +-
drivers/net/ethernet/mipsnet.c | 2 +-
drivers/net/ethernet/natsemi/macsonic.c | 2 +-
drivers/net/ethernet/rdc/r6040.c | 2 +-
drivers/net/ethernet/sis/sis900.c | 2 +-
drivers/net/ethernet/smsc/smsc9420.c | 5 ++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
drivers/net/ethernet/toshiba/tc35815.c | 2 +-
drivers/net/ethernet/via/via-rhine.c | 2 +-
drivers/net/ifb.c | 2 +-
drivers/net/tun.c | 2 +-
drivers/net/usb/smsc75xx.c | 2 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/veth.c | 4 ++--
drivers/net/virtio_net.c | 2 +-
drivers/net/wan/hdlc_fr.c | 2 +-
drivers/net/wan/hdlc_raw_eth.c | 2 +-
net/ipv4/ip_gre.c | 2 +-
net/l2tp/l2tp_eth.c | 2 +-
24 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 2320068..0206c54 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -87,7 +87,7 @@ static void __init macb_get_hwaddr(struct macb *bp)
memcpy(bp->dev->dev_addr, addr, sizeof(addr));
} else {
netdev_info(bp->dev, "invalid hw address, using random\n");
- random_ether_addr(bp->dev->dev_addr);
+ eth_hw_addr_random(bp->dev);
}
}
diff --git a/drivers/net/ethernet/cirrus/ep93xx_eth.c b/drivers/net/ethernet/cirrus/ep93xx_eth.c
index 4317af8..3c02b88 100644
--- a/drivers/net/ethernet/cirrus/ep93xx_eth.c
+++ b/drivers/net/ethernet/cirrus/ep93xx_eth.c
@@ -859,7 +859,7 @@ static int ep93xx_eth_probe(struct platform_device *pdev)
ep->mdc_divisor = 40; /* Max HCLK 100 MHz, min MDIO clk 2.5 MHz. */
if (is_zero_ether_addr(dev->dev_addr))
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
err = register_netdev(dev);
if (err) {
diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
index f801754..8400179 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1587,7 +1587,7 @@ dm9000_probe(struct platform_device *pdev)
dev_warn(db->dev, "%s: Invalid ethernet MAC address. Please "
"set using ifconfig\n", ndev->name);
- random_ether_addr(ndev->dev_addr);
+ eth_hw_addr_random(ndev);
mac_src = "random";
}
diff --git a/drivers/net/ethernet/dnet.c b/drivers/net/ethernet/dnet.c
index 925c9ba..051758b 100644
--- a/drivers/net/ethernet/dnet.c
+++ b/drivers/net/ethernet/dnet.c
@@ -897,7 +897,7 @@ static int __devinit dnet_probe(struct platform_device *pdev)
if (!is_valid_ether_addr(dev->dev_addr)) {
/* choose a random ethernet address */
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
__dnet_set_hwaddr(bp);
}
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 47f85c3..16b0704 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -1289,7 +1289,7 @@ static int ftgmac100_probe(struct platform_device *pdev)
netdev_info(netdev, "irq %d, mapped at %p\n", priv->irq, priv->base);
if (!is_valid_ether_addr(netdev->dev_addr)) {
- random_ether_addr(netdev->dev_addr);
+ eth_hw_addr_random(netdev);
netdev_info(netdev, "generated random MAC address %pM\n",
netdev->dev_addr);
}
diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
index bb336a0..829b109 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -1133,7 +1133,7 @@ static int ftmac100_probe(struct platform_device *pdev)
netdev_info(netdev, "irq %d, mapped at %p\n", priv->irq, priv->base);
if (!is_valid_ether_addr(netdev->dev_addr)) {
- random_ether_addr(netdev->dev_addr);
+ eth_hw_addr_random(netdev);
netdev_info(netdev, "generated random MAC address %pM\n",
netdev->dev_addr);
}
diff --git a/drivers/net/ethernet/mipsnet.c b/drivers/net/ethernet/mipsnet.c
index d05b0c9..771ce9b 100644
--- a/drivers/net/ethernet/mipsnet.c
+++ b/drivers/net/ethernet/mipsnet.c
@@ -281,7 +281,7 @@ static int __devinit mipsnet_probe(struct platform_device *dev)
* Lacking any better mechanism to allocate a MAC address we use a
* random one ...
*/
- random_ether_addr(netdev->dev_addr);
+ eth_hw_addr_random(netdev);
err = register_netdev(netdev);
if (err) {
diff --git a/drivers/net/ethernet/natsemi/macsonic.c b/drivers/net/ethernet/natsemi/macsonic.c
index f1b8556..e640e23 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -307,7 +307,7 @@ static void __devinit mac_onboard_sonic_ethernet_addr(struct net_device *dev)
printk(KERN_WARNING "macsonic: MAC address in CAM entry 15 "
"seems invalid, will use a random MAC\n");
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
}
static int __devinit mac_onboard_sonic_probe(struct net_device *dev)
diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index cb0eca8..6ba3ff4 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -1152,7 +1152,7 @@ static int __devinit r6040_init_one(struct pci_dev *pdev,
if (!(adrp[0] || adrp[1] || adrp[2])) {
netdev_warn(dev, "MAC address not initialized, "
"generating random\n");
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
}
/* Link new device into r6040_root_dev */
diff --git a/drivers/net/ethernet/sis/sis900.c b/drivers/net/ethernet/sis/sis900.c
index c8efc70..79e6c37 100644
--- a/drivers/net/ethernet/sis/sis900.c
+++ b/drivers/net/ethernet/sis/sis900.c
@@ -527,7 +527,7 @@ static int __devinit sis900_probe(struct pci_dev *pci_dev,
ret = sis900_get_mac_addr(pci_dev, net_dev);
if (!ret || !is_valid_ether_addr(net_dev->dev_addr)) {
- random_ether_addr(net_dev->dev_addr);
+ eth_hw_addr_random(net_dev);
printk(KERN_WARNING "%s: Unreadable or invalid MAC address,"
"using random generated one\n", dev_name);
}
diff --git a/drivers/net/ethernet/smsc/smsc9420.c b/drivers/net/ethernet/smsc/smsc9420.c
index a9efbdf..8cc47ad 100644
--- a/drivers/net/ethernet/smsc/smsc9420.c
+++ b/drivers/net/ethernet/smsc/smsc9420.c
@@ -509,10 +509,9 @@ static void smsc9420_check_mac_address(struct net_device *dev)
smsc_dbg(PROBE, "Mac Address is read from EEPROM");
} else {
/* eeprom values are invalid, generate random MAC */
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
smsc9420_set_mac_address(dev);
- smsc_dbg(PROBE,
- "MAC Address is set to random_ether_addr");
+ smsc_dbg(PROBE, "MAC Address is set to random");
}
}
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 96fa2da..a361ee9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -910,7 +910,7 @@ static void stmmac_check_ether_addr(struct stmmac_priv *priv)
priv->dev->base_addr,
priv->dev->dev_addr, 0);
if (!is_valid_ether_addr(priv->dev->dev_addr))
- random_ether_addr(priv->dev->dev_addr);
+ eth_hw_addr_random(priv->dev);
}
pr_warning("%s: device MAC address %pM\n", priv->dev->name,
priv->dev->dev_addr);
diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c
index 71b785c..4754f00 100644
--- a/drivers/net/ethernet/toshiba/tc35815.c
+++ b/drivers/net/ethernet/toshiba/tc35815.c
@@ -850,7 +850,7 @@ static int __devinit tc35815_init_one(struct pci_dev *pdev,
/* Retrieve the ethernet address. */
if (tc35815_init_dev_addr(dev)) {
dev_warn(&pdev->dev, "not valid ether addr\n");
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
}
rc = register_netdev(dev);
diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
index 10b18eb..ccd5921 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -984,7 +984,7 @@ static int __devinit rhine_init_one(struct pci_dev *pdev,
if (!is_valid_ether_addr(dev->dev_addr)) {
/* Report it and use a random ethernet address instead */
netdev_err(dev, "Invalid MAC address: %pM\n", dev->dev_addr);
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
netdev_info(dev, "Using random MAC address: %pM\n",
dev->dev_addr);
}
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index e05b645..344dceb 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -184,7 +184,7 @@ static void ifb_setup(struct net_device *dev)
dev->flags |= IFF_NOARP;
dev->flags &= ~IFF_MULTICAST;
dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE | IFF_TX_SKB_SHARING);
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
}
static netdev_tx_t ifb_xmit(struct sk_buff *skb, struct net_device *dev)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 93c5d72..2c5d349 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -531,7 +531,7 @@ static void tun_net_init(struct net_device *dev)
ether_setup(dev);
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
dev->tx_queue_len = TUN_READQ_SIZE; /* We prefer our own queue length */
break;
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 3b017bb..187d01c 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -615,7 +615,7 @@ static void smsc75xx_init_mac_address(struct usbnet *dev)
}
/* no eeprom, or eeprom values are invalid. generate random MAC */
- random_ether_addr(dev->net->dev_addr);
+ eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to random_ether_addr");
}
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index d45520e..5f19f84 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -614,7 +614,7 @@ static void smsc95xx_init_mac_address(struct usbnet *dev)
}
/* no eeprom, or eeprom values are invalid. generate random MAC */
- random_ether_addr(dev->net->dev_addr);
+ eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to random_ether_addr\n");
}
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 49f4667..b8a697f 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -346,7 +346,7 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
}
if (tbp[IFLA_ADDRESS] == NULL)
- random_ether_addr(peer->dev_addr);
+ eth_hw_addr_random(peer);
err = register_netdevice(peer);
put_net(net);
@@ -368,7 +368,7 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
*/
if (tb[IFLA_ADDRESS] == NULL)
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
if (tb[IFLA_IFNAME])
nla_strlcpy(dev->name, tb[IFLA_IFNAME], IFNAMSIZ);
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4880aa8..bc2cb11 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1061,7 +1061,7 @@ static int virtnet_probe(struct virtio_device *vdev)
if (virtio_config_val_len(vdev, VIRTIO_NET_F_MAC,
offsetof(struct virtio_net_config, mac),
dev->dev_addr, dev->addr_len) < 0)
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
/* Set up our device-specific information */
vi = netdev_priv(dev);
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index eb20281..7c6cb4f3 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net/wan/hdlc_fr.c
@@ -1087,7 +1087,7 @@ static int fr_add_pvc(struct net_device *frad, unsigned int dlci, int type)
}
if (type == ARPHRD_ETHER)
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
else {
*(__be16*)dev->dev_addr = htons(dlci);
dlci_to_q922(dev->broadcast, dlci);
diff --git a/drivers/net/wan/hdlc_raw_eth.c b/drivers/net/wan/hdlc_raw_eth.c
index 05c9b0b..3ab72b3 100644
--- a/drivers/net/wan/hdlc_raw_eth.c
+++ b/drivers/net/wan/hdlc_raw_eth.c
@@ -101,7 +101,7 @@ static int raw_eth_ioctl(struct net_device *dev, struct ifreq *ifr)
old_qlen = dev->tx_queue_len;
ether_setup(dev);
dev->tx_queue_len = old_qlen;
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
netif_dormant_off(dev);
return 0;
}
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 6b3ca5b..9b1fb61 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1529,7 +1529,7 @@ static int ipgre_newlink(struct net *src_net, struct net_device *dev, struct nla
return -EEXIST;
if (dev->type == ARPHRD_ETHER && !tb[IFLA_ADDRESS])
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
mtu = ipgre_tunnel_bind_dev(dev);
if (!tb[IFLA_MTU])
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index d2726a7..63fe5f3 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -64,7 +64,7 @@ static int l2tp_eth_dev_init(struct net_device *dev)
struct l2tp_eth *priv = netdev_priv(dev);
priv->dev = dev;
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
memset(&dev->broadcast[0], 0xff, 6);
return 0;
--
1.7.8.3
^ permalink raw reply related
* [RESEND][PATCH v2 0/2] Part 2: handle addr_assign_type for random addresses
From: Danny Kukawka @ 2012-02-15 16:45 UTC (permalink / raw)
To: David S. Miller
Cc: Michael S. Tsirkin, Nicolas Ferre, Eilon Greenstein, Roger Luethi,
Daniele Venzano, Stephen Hemminger, dev, Danny Kukawka,
James Morris, Alexey Kuznetsov, Jesse Gross,
bridge@lists.linux-foundation.org Chris Metcalf,
Giuseppe Cavallaro, virtualization, Florian Fainelli, Jiri Pirko,
Hideaki YOSHIFUJI, Greg Kroah-Hartman, linux-usb, linux-kernel,
Hartley Sweeten, netdev, Steve Glendinning <steve.glendi>
The second part of my patch series to fix the handling of
addr_assign_type for random MAC addresses. This contains the
trival changes from random_ether_addr() to new
eth_hw_addr_random() and code to reset the state to
NET_ADDR_PERM as soon as the MAC get changed via
.ndo_set_mac_address where eth_mac_addr wasn't used.
Resend due to send with too long recipients list. Sorry!
Thanks to Joe Perches for the hint.
Danny Kukawka (2):
net: replace random_ether_addr() with eth_hw_addr_random()
net: use eth_hw_addr_random() and reset addr_assign_type
drivers/net/dummy.c | 3 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
drivers/net/ethernet/cadence/macb.c | 2 +-
drivers/net/ethernet/calxeda/xgmac.c | 3 ++-
drivers/net/ethernet/cirrus/ep93xx_eth.c | 2 +-
drivers/net/ethernet/davicom/dm9000.c | 2 +-
drivers/net/ethernet/dnet.c | 2 +-
drivers/net/ethernet/faraday/ftgmac100.c | 2 +-
drivers/net/ethernet/faraday/ftmac100.c | 2 +-
drivers/net/ethernet/marvell/pxa168_eth.c | 3 ++-
drivers/net/ethernet/micrel/ks8842.c | 3 ++-
drivers/net/ethernet/micrel/ks8851.c | 3 ++-
drivers/net/ethernet/micrel/ks8851_mll.c | 1 +
drivers/net/ethernet/microchip/enc28j60.c | 3 ++-
drivers/net/ethernet/mipsnet.c | 2 +-
drivers/net/ethernet/natsemi/macsonic.c | 2 +-
drivers/net/ethernet/nvidia/forcedeth.c | 3 ++-
drivers/net/ethernet/rdc/r6040.c | 2 +-
drivers/net/ethernet/sis/sis900.c | 2 +-
drivers/net/ethernet/smsc/smsc911x.c | 3 ++-
drivers/net/ethernet/smsc/smsc9420.c | 5 ++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
drivers/net/ethernet/tile/tilepro.c | 3 ++-
drivers/net/ethernet/toshiba/tc35815.c | 2 +-
drivers/net/ethernet/via/via-rhine.c | 2 +-
drivers/net/ifb.c | 2 +-
drivers/net/macvlan.c | 3 ++-
drivers/net/team/team.c | 3 ++-
drivers/net/tun.c | 2 +-
drivers/net/usb/smsc75xx.c | 2 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/veth.c | 4 ++--
drivers/net/virtio_net.c | 2 +-
drivers/net/wan/hdlc_fr.c | 2 +-
drivers/net/wan/hdlc_raw_eth.c | 2 +-
net/bridge/br_device.c | 3 ++-
net/ipv4/ip_gre.c | 2 +-
net/l2tp/l2tp_eth.c | 2 +-
net/openvswitch/vport-internal_dev.c | 3 ++-
40 files changed, 55 insertions(+), 41 deletions(-)
--
1.7.8.3
^ permalink raw reply
* [PATCH v2 1/2] net: replace random_ether_addr() with eth_hw_addr_random()
From: Danny Kukawka @ 2012-02-15 14:53 UTC (permalink / raw)
To: David S. Miller
Cc: Mark Brown, Michael S. Tsirkin, Nicolas Ferre, James Morris,
Daniele Venzano, Stephen Hemminger, Wan ZongShun, Eric Dumazet,
Danny Kukawka, James Chapman, Jeff Kirsher, Alexey Kuznetsov,
virtualization, Alexey Dobriyan, Paul, Po-Yu Chuang,
Lucas De Marchi, Rick Jones, Jamal Hadi Salim,
Michał Mirosław, Ben Dooks
In-Reply-To: <1329317595-2031-1-git-send-email-danny.kukawka@bisect.de>
Replace usage of random_ether_addr() with eth_hw_addr_random()
to set addr_assign_type correctly to NET_ADDR_RANDOM.
Change the trivial cases.
v2: adapt to renamed eth_hw_addr_random()
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
---
drivers/net/ethernet/cadence/macb.c | 2 +-
drivers/net/ethernet/cirrus/ep93xx_eth.c | 2 +-
drivers/net/ethernet/davicom/dm9000.c | 2 +-
drivers/net/ethernet/dnet.c | 2 +-
drivers/net/ethernet/faraday/ftgmac100.c | 2 +-
drivers/net/ethernet/faraday/ftmac100.c | 2 +-
drivers/net/ethernet/mipsnet.c | 2 +-
drivers/net/ethernet/natsemi/macsonic.c | 2 +-
drivers/net/ethernet/rdc/r6040.c | 2 +-
drivers/net/ethernet/sis/sis900.c | 2 +-
drivers/net/ethernet/smsc/smsc9420.c | 5 ++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
drivers/net/ethernet/toshiba/tc35815.c | 2 +-
drivers/net/ethernet/via/via-rhine.c | 2 +-
drivers/net/ifb.c | 2 +-
drivers/net/tun.c | 2 +-
drivers/net/usb/smsc75xx.c | 2 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/veth.c | 4 ++--
drivers/net/virtio_net.c | 2 +-
drivers/net/wan/hdlc_fr.c | 2 +-
drivers/net/wan/hdlc_raw_eth.c | 2 +-
net/ipv4/ip_gre.c | 2 +-
net/l2tp/l2tp_eth.c | 2 +-
24 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 2320068..0206c54 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -87,7 +87,7 @@ static void __init macb_get_hwaddr(struct macb *bp)
memcpy(bp->dev->dev_addr, addr, sizeof(addr));
} else {
netdev_info(bp->dev, "invalid hw address, using random\n");
- random_ether_addr(bp->dev->dev_addr);
+ eth_hw_addr_random(bp->dev);
}
}
diff --git a/drivers/net/ethernet/cirrus/ep93xx_eth.c b/drivers/net/ethernet/cirrus/ep93xx_eth.c
index 4317af8..3c02b88 100644
--- a/drivers/net/ethernet/cirrus/ep93xx_eth.c
+++ b/drivers/net/ethernet/cirrus/ep93xx_eth.c
@@ -859,7 +859,7 @@ static int ep93xx_eth_probe(struct platform_device *pdev)
ep->mdc_divisor = 40; /* Max HCLK 100 MHz, min MDIO clk 2.5 MHz. */
if (is_zero_ether_addr(dev->dev_addr))
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
err = register_netdev(dev);
if (err) {
diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
index f801754..8400179 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1587,7 +1587,7 @@ dm9000_probe(struct platform_device *pdev)
dev_warn(db->dev, "%s: Invalid ethernet MAC address. Please "
"set using ifconfig\n", ndev->name);
- random_ether_addr(ndev->dev_addr);
+ eth_hw_addr_random(ndev);
mac_src = "random";
}
diff --git a/drivers/net/ethernet/dnet.c b/drivers/net/ethernet/dnet.c
index 925c9ba..051758b 100644
--- a/drivers/net/ethernet/dnet.c
+++ b/drivers/net/ethernet/dnet.c
@@ -897,7 +897,7 @@ static int __devinit dnet_probe(struct platform_device *pdev)
if (!is_valid_ether_addr(dev->dev_addr)) {
/* choose a random ethernet address */
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
__dnet_set_hwaddr(bp);
}
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 47f85c3..16b0704 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -1289,7 +1289,7 @@ static int ftgmac100_probe(struct platform_device *pdev)
netdev_info(netdev, "irq %d, mapped at %p\n", priv->irq, priv->base);
if (!is_valid_ether_addr(netdev->dev_addr)) {
- random_ether_addr(netdev->dev_addr);
+ eth_hw_addr_random(netdev);
netdev_info(netdev, "generated random MAC address %pM\n",
netdev->dev_addr);
}
diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
index bb336a0..829b109 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -1133,7 +1133,7 @@ static int ftmac100_probe(struct platform_device *pdev)
netdev_info(netdev, "irq %d, mapped at %p\n", priv->irq, priv->base);
if (!is_valid_ether_addr(netdev->dev_addr)) {
- random_ether_addr(netdev->dev_addr);
+ eth_hw_addr_random(netdev);
netdev_info(netdev, "generated random MAC address %pM\n",
netdev->dev_addr);
}
diff --git a/drivers/net/ethernet/mipsnet.c b/drivers/net/ethernet/mipsnet.c
index d05b0c9..771ce9b 100644
--- a/drivers/net/ethernet/mipsnet.c
+++ b/drivers/net/ethernet/mipsnet.c
@@ -281,7 +281,7 @@ static int __devinit mipsnet_probe(struct platform_device *dev)
* Lacking any better mechanism to allocate a MAC address we use a
* random one ...
*/
- random_ether_addr(netdev->dev_addr);
+ eth_hw_addr_random(netdev);
err = register_netdev(netdev);
if (err) {
diff --git a/drivers/net/ethernet/natsemi/macsonic.c b/drivers/net/ethernet/natsemi/macsonic.c
index f1b8556..e640e23 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -307,7 +307,7 @@ static void __devinit mac_onboard_sonic_ethernet_addr(struct net_device *dev)
printk(KERN_WARNING "macsonic: MAC address in CAM entry 15 "
"seems invalid, will use a random MAC\n");
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
}
static int __devinit mac_onboard_sonic_probe(struct net_device *dev)
diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index cb0eca8..6ba3ff4 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -1152,7 +1152,7 @@ static int __devinit r6040_init_one(struct pci_dev *pdev,
if (!(adrp[0] || adrp[1] || adrp[2])) {
netdev_warn(dev, "MAC address not initialized, "
"generating random\n");
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
}
/* Link new device into r6040_root_dev */
diff --git a/drivers/net/ethernet/sis/sis900.c b/drivers/net/ethernet/sis/sis900.c
index c8efc70..79e6c37 100644
--- a/drivers/net/ethernet/sis/sis900.c
+++ b/drivers/net/ethernet/sis/sis900.c
@@ -527,7 +527,7 @@ static int __devinit sis900_probe(struct pci_dev *pci_dev,
ret = sis900_get_mac_addr(pci_dev, net_dev);
if (!ret || !is_valid_ether_addr(net_dev->dev_addr)) {
- random_ether_addr(net_dev->dev_addr);
+ eth_hw_addr_random(net_dev);
printk(KERN_WARNING "%s: Unreadable or invalid MAC address,"
"using random generated one\n", dev_name);
}
diff --git a/drivers/net/ethernet/smsc/smsc9420.c b/drivers/net/ethernet/smsc/smsc9420.c
index a9efbdf..8cc47ad 100644
--- a/drivers/net/ethernet/smsc/smsc9420.c
+++ b/drivers/net/ethernet/smsc/smsc9420.c
@@ -509,10 +509,9 @@ static void smsc9420_check_mac_address(struct net_device *dev)
smsc_dbg(PROBE, "Mac Address is read from EEPROM");
} else {
/* eeprom values are invalid, generate random MAC */
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
smsc9420_set_mac_address(dev);
- smsc_dbg(PROBE,
- "MAC Address is set to random_ether_addr");
+ smsc_dbg(PROBE, "MAC Address is set to random");
}
}
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 96fa2da..a361ee9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -910,7 +910,7 @@ static void stmmac_check_ether_addr(struct stmmac_priv *priv)
priv->dev->base_addr,
priv->dev->dev_addr, 0);
if (!is_valid_ether_addr(priv->dev->dev_addr))
- random_ether_addr(priv->dev->dev_addr);
+ eth_hw_addr_random(priv->dev);
}
pr_warning("%s: device MAC address %pM\n", priv->dev->name,
priv->dev->dev_addr);
diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c
index 71b785c..4754f00 100644
--- a/drivers/net/ethernet/toshiba/tc35815.c
+++ b/drivers/net/ethernet/toshiba/tc35815.c
@@ -850,7 +850,7 @@ static int __devinit tc35815_init_one(struct pci_dev *pdev,
/* Retrieve the ethernet address. */
if (tc35815_init_dev_addr(dev)) {
dev_warn(&pdev->dev, "not valid ether addr\n");
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
}
rc = register_netdev(dev);
diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
index 10b18eb..ccd5921 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -984,7 +984,7 @@ static int __devinit rhine_init_one(struct pci_dev *pdev,
if (!is_valid_ether_addr(dev->dev_addr)) {
/* Report it and use a random ethernet address instead */
netdev_err(dev, "Invalid MAC address: %pM\n", dev->dev_addr);
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
netdev_info(dev, "Using random MAC address: %pM\n",
dev->dev_addr);
}
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index e05b645..344dceb 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -184,7 +184,7 @@ static void ifb_setup(struct net_device *dev)
dev->flags |= IFF_NOARP;
dev->flags &= ~IFF_MULTICAST;
dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE | IFF_TX_SKB_SHARING);
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
}
static netdev_tx_t ifb_xmit(struct sk_buff *skb, struct net_device *dev)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 93c5d72..2c5d349 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -531,7 +531,7 @@ static void tun_net_init(struct net_device *dev)
ether_setup(dev);
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
dev->tx_queue_len = TUN_READQ_SIZE; /* We prefer our own queue length */
break;
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 3b017bb..187d01c 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -615,7 +615,7 @@ static void smsc75xx_init_mac_address(struct usbnet *dev)
}
/* no eeprom, or eeprom values are invalid. generate random MAC */
- random_ether_addr(dev->net->dev_addr);
+ eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to random_ether_addr");
}
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index d45520e..5f19f84 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -614,7 +614,7 @@ static void smsc95xx_init_mac_address(struct usbnet *dev)
}
/* no eeprom, or eeprom values are invalid. generate random MAC */
- random_ether_addr(dev->net->dev_addr);
+ eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to random_ether_addr\n");
}
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 49f4667..b8a697f 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -346,7 +346,7 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
}
if (tbp[IFLA_ADDRESS] == NULL)
- random_ether_addr(peer->dev_addr);
+ eth_hw_addr_random(peer);
err = register_netdevice(peer);
put_net(net);
@@ -368,7 +368,7 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
*/
if (tb[IFLA_ADDRESS] == NULL)
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
if (tb[IFLA_IFNAME])
nla_strlcpy(dev->name, tb[IFLA_IFNAME], IFNAMSIZ);
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4880aa8..bc2cb11 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1061,7 +1061,7 @@ static int virtnet_probe(struct virtio_device *vdev)
if (virtio_config_val_len(vdev, VIRTIO_NET_F_MAC,
offsetof(struct virtio_net_config, mac),
dev->dev_addr, dev->addr_len) < 0)
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
/* Set up our device-specific information */
vi = netdev_priv(dev);
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index eb20281..7c6cb4f3 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net/wan/hdlc_fr.c
@@ -1087,7 +1087,7 @@ static int fr_add_pvc(struct net_device *frad, unsigned int dlci, int type)
}
if (type == ARPHRD_ETHER)
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
else {
*(__be16*)dev->dev_addr = htons(dlci);
dlci_to_q922(dev->broadcast, dlci);
diff --git a/drivers/net/wan/hdlc_raw_eth.c b/drivers/net/wan/hdlc_raw_eth.c
index 05c9b0b..3ab72b3 100644
--- a/drivers/net/wan/hdlc_raw_eth.c
+++ b/drivers/net/wan/hdlc_raw_eth.c
@@ -101,7 +101,7 @@ static int raw_eth_ioctl(struct net_device *dev, struct ifreq *ifr)
old_qlen = dev->tx_queue_len;
ether_setup(dev);
dev->tx_queue_len = old_qlen;
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
netif_dormant_off(dev);
return 0;
}
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 6b3ca5b..9b1fb61 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1529,7 +1529,7 @@ static int ipgre_newlink(struct net *src_net, struct net_device *dev, struct nla
return -EEXIST;
if (dev->type == ARPHRD_ETHER && !tb[IFLA_ADDRESS])
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
mtu = ipgre_tunnel_bind_dev(dev);
if (!tb[IFLA_MTU])
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index d2726a7..63fe5f3 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -64,7 +64,7 @@ static int l2tp_eth_dev_init(struct net_device *dev)
struct l2tp_eth *priv = netdev_priv(dev);
priv->dev = dev;
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
memset(&dev->broadcast[0], 0xff, 6);
return 0;
--
1.7.8.3
^ permalink raw reply related
* [PATCH v2 0/2] Part 2: handle addr_assign_type for random addresses
From: Danny Kukawka @ 2012-02-15 14:53 UTC (permalink / raw)
To: David S. Miller
Cc: Jiri Kosina, Nicolas Ferre, Eilon Greenstein, James Morris,
Daniele Venzano, Dennis Aberilla, Stephen Hemminger,
David Decotigny, Wan ZongShun, Thomas Meyer, dev, Samuel Ortiz,
Eric Dumazet, bridge, Danny Kukawka, James Chapman,
Simtec Linux Team, Jeff Kirsher, Alexey Kuznetsov, Jon Mason,
virtualization, Alexey Dobriyan, Paul, Rick Jones
The second part of my patch series to fix the handling of
addr_assign_type for random MAC addresses. This contains the
trival changes from random_ether_addr() to new
eth_hw_addr_random() and code to reset the state to
NET_ADDR_PERM as soon as the MAC get changed via
.ndo_set_mac_address where eth_mac_addr wasn't used.
Danny Kukawka (2):
net: replace random_ether_addr() with eth_hw_addr_random()
net: use eth_hw_addr_random() and reset addr_assign_type
drivers/net/dummy.c | 3 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
drivers/net/ethernet/cadence/macb.c | 2 +-
drivers/net/ethernet/calxeda/xgmac.c | 3 ++-
drivers/net/ethernet/cirrus/ep93xx_eth.c | 2 +-
drivers/net/ethernet/davicom/dm9000.c | 2 +-
drivers/net/ethernet/dnet.c | 2 +-
drivers/net/ethernet/faraday/ftgmac100.c | 2 +-
drivers/net/ethernet/faraday/ftmac100.c | 2 +-
drivers/net/ethernet/marvell/pxa168_eth.c | 3 ++-
drivers/net/ethernet/micrel/ks8842.c | 3 ++-
drivers/net/ethernet/micrel/ks8851.c | 3 ++-
drivers/net/ethernet/micrel/ks8851_mll.c | 1 +
drivers/net/ethernet/microchip/enc28j60.c | 3 ++-
drivers/net/ethernet/mipsnet.c | 2 +-
drivers/net/ethernet/natsemi/macsonic.c | 2 +-
drivers/net/ethernet/nvidia/forcedeth.c | 3 ++-
drivers/net/ethernet/rdc/r6040.c | 2 +-
drivers/net/ethernet/sis/sis900.c | 2 +-
drivers/net/ethernet/smsc/smsc911x.c | 3 ++-
drivers/net/ethernet/smsc/smsc9420.c | 5 ++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
drivers/net/ethernet/tile/tilepro.c | 3 ++-
drivers/net/ethernet/toshiba/tc35815.c | 2 +-
drivers/net/ethernet/via/via-rhine.c | 2 +-
drivers/net/ifb.c | 2 +-
drivers/net/macvlan.c | 3 ++-
drivers/net/team/team.c | 3 ++-
drivers/net/tun.c | 2 +-
drivers/net/usb/smsc75xx.c | 2 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/veth.c | 4 ++--
drivers/net/virtio_net.c | 2 +-
drivers/net/wan/hdlc_fr.c | 2 +-
drivers/net/wan/hdlc_raw_eth.c | 2 +-
net/bridge/br_device.c | 3 ++-
net/ipv4/ip_gre.c | 2 +-
net/l2tp/l2tp_eth.c | 2 +-
net/openvswitch/vport-internal_dev.c | 3 ++-
40 files changed, 55 insertions(+), 41 deletions(-)
--
1.7.8.3
^ permalink raw reply
* Is there a reference count for ksm shared page?
From: Jidong Xiao @ 2012-02-14 2:17 UTC (permalink / raw)
To: linux-mm; +Cc: virtualization
Hi,
I use madvise() system call to claim that my pages are mergeable, but
for some reason I want to see how many pages are shared with my pages,
is there a way to know that? For example, something like a reference
count.
Thank you!
Jidong
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: KY Srinivasan @ 2012-02-13 19:31 UTC (permalink / raw)
To: James Bottomley, Greg KH
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org, ohering@suse.com,
hch@infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <1329161318.20751.30.camel@dabdike>
> -----Original Message-----
> From: James Bottomley [mailto:jbottomley@parallels.com]
> Sent: Monday, February 13, 2012 2:29 PM
> To: Greg KH
> Cc: KY Srinivasan; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> scsi@vger.kernel.org
> Subject: Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the
> staging area
>
> On Fri, 2012-02-10 at 10:02 -0800, Greg KH wrote:
> > On Thu, Feb 09, 2012 at 02:14:48PM -0800, K. Y. Srinivasan wrote:
> > > The storage driver (storvsc_drv.c) handles all block storage devices
> > > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > > staging tree for a while and this patch moves it out of the staging area.
> > >
> > > James was willing to apply this patch during the 3.3-rc phase and a decision
> > > was taken to defer this to 3.4 since Greg had queued up a bunch of storvsc
> > > patches for 3.4. Now that Greg has applied all of the pending storvsc patches,
> > > I am sending this patch to move this driver out of staging. Based on James'
> > > recommendation, this patch gets rid of the unneeded files in the staging/hv
> > > directory.
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > ---
> > > drivers/scsi/Kconfig | 7 +++++++
> > > drivers/scsi/Makefile | 3 +++
> > > drivers/{staging/hv => scsi}/storvsc_drv.c | 0
> > > drivers/staging/Kconfig | 2 --
> > > drivers/staging/Makefile | 1 -
> > > drivers/staging/hv/Kconfig | 5 -----
> > > drivers/staging/hv/Makefile | 3 ---
> > > drivers/staging/hv/TODO | 5 -----
> > > 8 files changed, 10 insertions(+), 16 deletions(-)
> > > rename drivers/{staging/hv => scsi}/storvsc_drv.c (100%)
> > > delete mode 100644 drivers/staging/hv/Kconfig
> > > delete mode 100644 drivers/staging/hv/Makefile
> > > delete mode 100644 drivers/staging/hv/TODO
> >
> > James, can I add your Acked-by: for this patch?
>
> Yes ... i finally managed to pull your tree down and verify it.
>
> Acked-by: James Bottomley <JBottomley@Parallels.com>
Thank you.
K. Y
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: James Bottomley @ 2012-02-13 19:28 UTC (permalink / raw)
To: Greg KH
Cc: K. Y. Srinivasan, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, hch@infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <20120210180212.GA605@kroah.com>
On Fri, 2012-02-10 at 10:02 -0800, Greg KH wrote:
> On Thu, Feb 09, 2012 at 02:14:48PM -0800, K. Y. Srinivasan wrote:
> > The storage driver (storvsc_drv.c) handles all block storage devices
> > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > staging tree for a while and this patch moves it out of the staging area.
> >
> > James was willing to apply this patch during the 3.3-rc phase and a decision
> > was taken to defer this to 3.4 since Greg had queued up a bunch of storvsc
> > patches for 3.4. Now that Greg has applied all of the pending storvsc patches,
> > I am sending this patch to move this driver out of staging. Based on James'
> > recommendation, this patch gets rid of the unneeded files in the staging/hv
> > directory.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> > drivers/scsi/Kconfig | 7 +++++++
> > drivers/scsi/Makefile | 3 +++
> > drivers/{staging/hv => scsi}/storvsc_drv.c | 0
> > drivers/staging/Kconfig | 2 --
> > drivers/staging/Makefile | 1 -
> > drivers/staging/hv/Kconfig | 5 -----
> > drivers/staging/hv/Makefile | 3 ---
> > drivers/staging/hv/TODO | 5 -----
> > 8 files changed, 10 insertions(+), 16 deletions(-)
> > rename drivers/{staging/hv => scsi}/storvsc_drv.c (100%)
> > delete mode 100644 drivers/staging/hv/Kconfig
> > delete mode 100644 drivers/staging/hv/Makefile
> > delete mode 100644 drivers/staging/hv/TODO
>
> James, can I add your Acked-by: for this patch?
Yes ... i finally managed to pull your tree down and verify it.
Acked-by: James Bottomley <JBottomley@Parallels.com>
James
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: KY Srinivasan @ 2012-02-13 18:59 UTC (permalink / raw)
To: Greg KH, jbottomley@parallels.com
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org, ohering@suse.com,
hch@infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <20120210180212.GA605@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Friday, February 10, 2012 1:02 PM
> To: KY Srinivasan; jbottomley@parallels.com
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> scsi@vger.kernel.org
> Subject: Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the
> staging area
>
> On Thu, Feb 09, 2012 at 02:14:48PM -0800, K. Y. Srinivasan wrote:
> > The storage driver (storvsc_drv.c) handles all block storage devices
> > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > staging tree for a while and this patch moves it out of the staging area.
> >
> > James was willing to apply this patch during the 3.3-rc phase and a decision
> > was taken to defer this to 3.4 since Greg had queued up a bunch of storvsc
> > patches for 3.4. Now that Greg has applied all of the pending storvsc patches,
> > I am sending this patch to move this driver out of staging. Based on James'
> > recommendation, this patch gets rid of the unneeded files in the staging/hv
> > directory.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> > drivers/scsi/Kconfig | 7 +++++++
> > drivers/scsi/Makefile | 3 +++
> > drivers/{staging/hv => scsi}/storvsc_drv.c | 0
> > drivers/staging/Kconfig | 2 --
> > drivers/staging/Makefile | 1 -
> > drivers/staging/hv/Kconfig | 5 -----
> > drivers/staging/hv/Makefile | 3 ---
> > drivers/staging/hv/TODO | 5 -----
> > 8 files changed, 10 insertions(+), 16 deletions(-)
> > rename drivers/{staging/hv => scsi}/storvsc_drv.c (100%)
> > delete mode 100644 drivers/staging/hv/Kconfig
> > delete mode 100644 drivers/staging/hv/Makefile
> > delete mode 100644 drivers/staging/hv/TODO
>
> James, can I add your Acked-by: for this patch?
James,
Based on my understanding of your comments, I think this is what you
wanted. So, what is the verdict.
Regards,
K. Y.
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: Greg KH @ 2012-02-10 18:02 UTC (permalink / raw)
To: K. Y. Srinivasan, jbottomley
Cc: linux-kernel, devel, virtualization, ohering, hch, linux-scsi
In-Reply-To: <1328825688-4337-1-git-send-email-kys@microsoft.com>
On Thu, Feb 09, 2012 at 02:14:48PM -0800, K. Y. Srinivasan wrote:
> The storage driver (storvsc_drv.c) handles all block storage devices
> assigned to Linux guests hosted on Hyper-V. This driver has been in the
> staging tree for a while and this patch moves it out of the staging area.
>
> James was willing to apply this patch during the 3.3-rc phase and a decision
> was taken to defer this to 3.4 since Greg had queued up a bunch of storvsc
> patches for 3.4. Now that Greg has applied all of the pending storvsc patches,
> I am sending this patch to move this driver out of staging. Based on James'
> recommendation, this patch gets rid of the unneeded files in the staging/hv
> directory.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> drivers/scsi/Kconfig | 7 +++++++
> drivers/scsi/Makefile | 3 +++
> drivers/{staging/hv => scsi}/storvsc_drv.c | 0
> drivers/staging/Kconfig | 2 --
> drivers/staging/Makefile | 1 -
> drivers/staging/hv/Kconfig | 5 -----
> drivers/staging/hv/Makefile | 3 ---
> drivers/staging/hv/TODO | 5 -----
> 8 files changed, 10 insertions(+), 16 deletions(-)
> rename drivers/{staging/hv => scsi}/storvsc_drv.c (100%)
> delete mode 100644 drivers/staging/hv/Kconfig
> delete mode 100644 drivers/staging/hv/Makefile
> delete mode 100644 drivers/staging/hv/TODO
James, can I add your Acked-by: for this patch?
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: KY Srinivasan @ 2012-02-10 11:12 UTC (permalink / raw)
To: James Bottomley
Cc: Greg KH, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, hch@infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <1328820356.2944.24.camel@dabdike.int.hansenpartnership.com>
> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Sent: Thursday, February 09, 2012 3:46 PM
> To: KY Srinivasan
> Cc: Greg KH; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> scsi@vger.kernel.org
> Subject: RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the
> staging area
>
> On Thu, 2012-02-09 at 20:43 +0000, KY Srinivasan wrote:
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Thursday, February 09, 2012 3:24 PM
> > > To: James Bottomley
> > > Cc: KY Srinivasan; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> > > scsi@vger.kernel.org
> > > Subject: Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of
> the
> > > staging area
> > >
> > > On Thu, Feb 09, 2012 at 02:18:38PM -0600, James Bottomley wrote:
> > > > On Thu, 2012-02-09 at 12:04 -0800, Greg KH wrote:
> > > > > On Thu, Feb 09, 2012 at 12:04:11PM -0800, K. Y. Srinivasan wrote:
> > > > > > The storage driver (storvsc_drv.c) handles all block storage devices
> > > > > > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > > > > > staging tree for a while and this patch moves it out of the staging area.
> > > > > > As per Greg's recommendation, this patch makes no changes to the
> > > staging/hv
> > > > > > directory. Once the driver moves out of staging, we will cleanup the
> > > > > > staging/hv directory.
> > > > > >
> > > > > > James was willing to apply this patch during the 3.3-rc phase and a
> decision
> > > > > > was taken to defer this to 3.4 since Greg had queued up a bunch of
> storvsc
> > > > > > patches for 3.4. Now that Greg has applied all of the pending storvsc
> > > patches,
> > > > > > I am re-sending this patch to move this driver out of staging.
> > > > > >
> > > > > >
> > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > > ---
> > > > > > drivers/scsi/Kconfig | 7 +
> > > > > > drivers/scsi/Makefile | 3 +
> > > > > > drivers/scsi/storvsc_drv.c | 1548
> > > ++++++++++++++++++++++++++++++++++++++++++++
> > > > > > 3 files changed, 1558 insertions(+), 0 deletions(-)
> > > > > > create mode 100644 drivers/scsi/storvsc_drv.c
> > > > >
> > > > > James, any objection to me applying this to the staging-next tree, and
> > > > > at the same time, deleting this version of the driver from the
> > > > > drivers/staging/hv/ directory?
> > > >
> > > > Well, yes, it has the same build failure as the previous one and that
> > > > will make it non bisectable.
> > >
> > > Ah, that would make things a bit difficult, KY, please test your
> > > patches...
> >
> > Greg,
> >
> > I pulled down your staging tree earlier today that had all the storvsc patches
> that you
> > checked in yesterday, applied this patch and built it (successfully).
>
> You're leaving remnants in staging.
>
> Move the damn thing and pull the config options from staging when you
> put them in SCSI.
James,
I have sent out a revised patch that does exactly what you are suggesting here.
If this is what you were looking for please ACK it.
Regards,
K. Y
^ permalink raw reply
* [PATCH 26/60] vhost: remove the second argument of k[un]map_atomic()
From: Cong Wang @ 2012-02-10 5:39 UTC (permalink / raw)
To: linux-kernel
Cc: Cong Wang, kvm, Michael S. Tsirkin, netdev, virtualization,
Andrew Morton
In-Reply-To: <1328852421-19678-1-git-send-email-amwang@redhat.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
drivers/vhost/vhost.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c14c42b..bdb2d64 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -937,9 +937,9 @@ static int set_bit_to_user(int nr, void __user *addr)
if (r < 0)
return r;
BUG_ON(r != 1);
- base = kmap_atomic(page, KM_USER0);
+ base = kmap_atomic(page);
set_bit(bit, base);
- kunmap_atomic(base, KM_USER0);
+ kunmap_atomic(base);
set_page_dirty_lock(page);
put_page(page);
return 0;
--
1.7.7.6
^ permalink raw reply related
* [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: K. Y. Srinivasan @ 2012-02-09 22:14 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization, ohering, jbottomley,
hch, linux-scsi
Cc: K. Y. Srinivasan
The storage driver (storvsc_drv.c) handles all block storage devices
assigned to Linux guests hosted on Hyper-V. This driver has been in the
staging tree for a while and this patch moves it out of the staging area.
James was willing to apply this patch during the 3.3-rc phase and a decision
was taken to defer this to 3.4 since Greg had queued up a bunch of storvsc
patches for 3.4. Now that Greg has applied all of the pending storvsc patches,
I am sending this patch to move this driver out of staging. Based on James'
recommendation, this patch gets rid of the unneeded files in the staging/hv
directory.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/scsi/Kconfig | 7 +++++++
drivers/scsi/Makefile | 3 +++
drivers/{staging/hv => scsi}/storvsc_drv.c | 0
drivers/staging/Kconfig | 2 --
drivers/staging/Makefile | 1 -
drivers/staging/hv/Kconfig | 5 -----
drivers/staging/hv/Makefile | 3 ---
drivers/staging/hv/TODO | 5 -----
8 files changed, 10 insertions(+), 16 deletions(-)
rename drivers/{staging/hv => scsi}/storvsc_drv.c (100%)
delete mode 100644 drivers/staging/hv/Kconfig
delete mode 100644 drivers/staging/hv/Makefile
delete mode 100644 drivers/staging/hv/TODO
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 16570aa..d3d18e8 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -662,6 +662,13 @@ config VMWARE_PVSCSI
To compile this driver as a module, choose M here: the
module will be called vmw_pvscsi.
+config HYPERV_STORAGE
+ tristate "Microsoft Hyper-V virtual storage driver"
+ depends on SCSI && HYPERV
+ default HYPERV
+ help
+ Select this option to enable the Hyper-V virtual storage driver.
+
config LIBFC
tristate "LibFC module"
select SCSI_FC_ATTRS
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 2b88749..e4c1a69 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_SCSI_BNX2_ISCSI) += libiscsi.o bnx2i/
obj-$(CONFIG_BE2ISCSI) += libiscsi.o be2iscsi/
obj-$(CONFIG_SCSI_PMCRAID) += pmcraid.o
obj-$(CONFIG_VMWARE_PVSCSI) += vmw_pvscsi.o
+obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o
obj-$(CONFIG_ARM) += arm/
@@ -170,6 +171,8 @@ scsi_mod-$(CONFIG_SCSI_PROC_FS) += scsi_proc.o
scsi_mod-y += scsi_trace.o
scsi_mod-$(CONFIG_PM) += scsi_pm.o
+hv_storvsc-y := storvsc_drv.o
+
scsi_tgt-y += scsi_tgt_lib.o scsi_tgt_if.o
sd_mod-objs := sd.o
diff --git a/drivers/staging/hv/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
similarity index 100%
rename from drivers/staging/hv/storvsc_drv.c
rename to drivers/scsi/storvsc_drv.c
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 783bc0a..eb914ce 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -78,8 +78,6 @@ source "drivers/staging/vt6655/Kconfig"
source "drivers/staging/vt6656/Kconfig"
-source "drivers/staging/hv/Kconfig"
-
source "drivers/staging/vme/Kconfig"
source "drivers/staging/sep/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 077a3f3..e6f14f5 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -30,7 +30,6 @@ obj-$(CONFIG_USB_SERIAL_QUATECH_USB2) += quatech_usb2/
obj-$(CONFIG_OCTEON_ETHERNET) += octeon/
obj-$(CONFIG_VT6655) += vt6655/
obj-$(CONFIG_VT6656) += vt6656/
-obj-$(CONFIG_HYPERV) += hv/
obj-$(CONFIG_VME_BUS) += vme/
obj-$(CONFIG_DX_SEP) += sep/
obj-$(CONFIG_IIO) += iio/
diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
deleted file mode 100644
index 60ac479..0000000
--- a/drivers/staging/hv/Kconfig
+++ /dev/null
@@ -1,5 +0,0 @@
-config HYPERV_STORAGE
- tristate "Microsoft Hyper-V virtual storage driver"
- depends on HYPERV && SCSI
- help
- Select this option to enable the Hyper-V virtual storage driver.
diff --git a/drivers/staging/hv/Makefile b/drivers/staging/hv/Makefile
deleted file mode 100644
index af95a6b..0000000
--- a/drivers/staging/hv/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o
-
-hv_storvsc-y := storvsc_drv.o
diff --git a/drivers/staging/hv/TODO b/drivers/staging/hv/TODO
deleted file mode 100644
index dea7d92..0000000
--- a/drivers/staging/hv/TODO
+++ /dev/null
@@ -1,5 +0,0 @@
-TODO:
- - audit the scsi driver
-
-Please send patches for this code to Greg Kroah-Hartman <gregkh@suse.de>,
-Haiyang Zhang <haiyangz@microsoft.com>, and K. Y. Srinivasan <kys@microsoft.com>
--
1.7.4.1
^ permalink raw reply related
* RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: KY Srinivasan @ 2012-02-09 22:13 UTC (permalink / raw)
To: James Bottomley
Cc: Greg KH, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, hch@infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <1328820356.2944.24.camel@dabdike.int.hansenpartnership.com>
> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Sent: Thursday, February 09, 2012 3:46 PM
> To: KY Srinivasan
> Cc: Greg KH; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> scsi@vger.kernel.org
> Subject: RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the
> staging area
>
> On Thu, 2012-02-09 at 20:43 +0000, KY Srinivasan wrote:
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Thursday, February 09, 2012 3:24 PM
> > > To: James Bottomley
> > > Cc: KY Srinivasan; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> > > scsi@vger.kernel.org
> > > Subject: Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of
> the
> > > staging area
> > >
> > > On Thu, Feb 09, 2012 at 02:18:38PM -0600, James Bottomley wrote:
> > > > On Thu, 2012-02-09 at 12:04 -0800, Greg KH wrote:
> > > > > On Thu, Feb 09, 2012 at 12:04:11PM -0800, K. Y. Srinivasan wrote:
> > > > > > The storage driver (storvsc_drv.c) handles all block storage devices
> > > > > > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > > > > > staging tree for a while and this patch moves it out of the staging area.
> > > > > > As per Greg's recommendation, this patch makes no changes to the
> > > staging/hv
> > > > > > directory. Once the driver moves out of staging, we will cleanup the
> > > > > > staging/hv directory.
> > > > > >
> > > > > > James was willing to apply this patch during the 3.3-rc phase and a
> decision
> > > > > > was taken to defer this to 3.4 since Greg had queued up a bunch of
> storvsc
> > > > > > patches for 3.4. Now that Greg has applied all of the pending storvsc
> > > patches,
> > > > > > I am re-sending this patch to move this driver out of staging.
> > > > > >
> > > > > >
> > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > > ---
> > > > > > drivers/scsi/Kconfig | 7 +
> > > > > > drivers/scsi/Makefile | 3 +
> > > > > > drivers/scsi/storvsc_drv.c | 1548
> > > ++++++++++++++++++++++++++++++++++++++++++++
> > > > > > 3 files changed, 1558 insertions(+), 0 deletions(-)
> > > > > > create mode 100644 drivers/scsi/storvsc_drv.c
> > > > >
> > > > > James, any objection to me applying this to the staging-next tree, and
> > > > > at the same time, deleting this version of the driver from the
> > > > > drivers/staging/hv/ directory?
> > > >
> > > > Well, yes, it has the same build failure as the previous one and that
> > > > will make it non bisectable.
> > >
> > > Ah, that would make things a bit difficult, KY, please test your
> > > patches...
> >
> > Greg,
> >
> > I pulled down your staging tree earlier today that had all the storvsc patches
> that you
> > checked in yesterday, applied this patch and built it (successfully).
>
> You're leaving remnants in staging.
>
> Move the damn thing and pull the config options from staging when you
> put them in SCSI.
I have now also sent out a patch that does what you are suggesting here.
Regards,
K. Y
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: KY Srinivasan @ 2012-02-09 20:51 UTC (permalink / raw)
To: James Bottomley
Cc: Greg KH, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, hch@infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <1328820356.2944.24.camel@dabdike.int.hansenpartnership.com>
> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Sent: Thursday, February 09, 2012 3:46 PM
> To: KY Srinivasan
> Cc: Greg KH; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> scsi@vger.kernel.org
> Subject: RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the
> staging area
>
> On Thu, 2012-02-09 at 20:43 +0000, KY Srinivasan wrote:
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Thursday, February 09, 2012 3:24 PM
> > > To: James Bottomley
> > > Cc: KY Srinivasan; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> > > scsi@vger.kernel.org
> > > Subject: Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of
> the
> > > staging area
> > >
> > > On Thu, Feb 09, 2012 at 02:18:38PM -0600, James Bottomley wrote:
> > > > On Thu, 2012-02-09 at 12:04 -0800, Greg KH wrote:
> > > > > On Thu, Feb 09, 2012 at 12:04:11PM -0800, K. Y. Srinivasan wrote:
> > > > > > The storage driver (storvsc_drv.c) handles all block storage devices
> > > > > > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > > > > > staging tree for a while and this patch moves it out of the staging area.
> > > > > > As per Greg's recommendation, this patch makes no changes to the
> > > staging/hv
> > > > > > directory. Once the driver moves out of staging, we will cleanup the
> > > > > > staging/hv directory.
> > > > > >
> > > > > > James was willing to apply this patch during the 3.3-rc phase and a
> decision
> > > > > > was taken to defer this to 3.4 since Greg had queued up a bunch of
> storvsc
> > > > > > patches for 3.4. Now that Greg has applied all of the pending storvsc
> > > patches,
> > > > > > I am re-sending this patch to move this driver out of staging.
> > > > > >
> > > > > >
> > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > > ---
> > > > > > drivers/scsi/Kconfig | 7 +
> > > > > > drivers/scsi/Makefile | 3 +
> > > > > > drivers/scsi/storvsc_drv.c | 1548
> > > ++++++++++++++++++++++++++++++++++++++++++++
> > > > > > 3 files changed, 1558 insertions(+), 0 deletions(-)
> > > > > > create mode 100644 drivers/scsi/storvsc_drv.c
> > > > >
> > > > > James, any objection to me applying this to the staging-next tree, and
> > > > > at the same time, deleting this version of the driver from the
> > > > > drivers/staging/hv/ directory?
> > > >
> > > > Well, yes, it has the same build failure as the previous one and that
> > > > will make it non bisectable.
> > >
> > > Ah, that would make things a bit difficult, KY, please test your
> > > patches...
> >
> > Greg,
> >
> > I pulled down your staging tree earlier today that had all the storvsc patches
> that you
> > checked in yesterday, applied this patch and built it (successfully).
>
> You're leaving remnants in staging.
>
> Move the damn thing and pull the config options from staging when you
> put them in SCSI.
Greg had recommended that the patch moving the driver should not delete the contents
in the staging directory and that he (Greg) would clean up the staging directory. Greg, let me
know if you want me to send you a patch that includes getting rid of the stuff from the staging area.
Regards,
K. Y
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: James Bottomley @ 2012-02-09 20:45 UTC (permalink / raw)
To: KY Srinivasan
Cc: Greg KH, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, hch@infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481B70CB38@TK5EX14MBXC128.redmond.corp.microsoft.com>
On Thu, 2012-02-09 at 20:43 +0000, KY Srinivasan wrote:
>
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Thursday, February 09, 2012 3:24 PM
> > To: James Bottomley
> > Cc: KY Srinivasan; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> > scsi@vger.kernel.org
> > Subject: Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the
> > staging area
> >
> > On Thu, Feb 09, 2012 at 02:18:38PM -0600, James Bottomley wrote:
> > > On Thu, 2012-02-09 at 12:04 -0800, Greg KH wrote:
> > > > On Thu, Feb 09, 2012 at 12:04:11PM -0800, K. Y. Srinivasan wrote:
> > > > > The storage driver (storvsc_drv.c) handles all block storage devices
> > > > > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > > > > staging tree for a while and this patch moves it out of the staging area.
> > > > > As per Greg's recommendation, this patch makes no changes to the
> > staging/hv
> > > > > directory. Once the driver moves out of staging, we will cleanup the
> > > > > staging/hv directory.
> > > > >
> > > > > James was willing to apply this patch during the 3.3-rc phase and a decision
> > > > > was taken to defer this to 3.4 since Greg had queued up a bunch of storvsc
> > > > > patches for 3.4. Now that Greg has applied all of the pending storvsc
> > patches,
> > > > > I am re-sending this patch to move this driver out of staging.
> > > > >
> > > > >
> > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > ---
> > > > > drivers/scsi/Kconfig | 7 +
> > > > > drivers/scsi/Makefile | 3 +
> > > > > drivers/scsi/storvsc_drv.c | 1548
> > ++++++++++++++++++++++++++++++++++++++++++++
> > > > > 3 files changed, 1558 insertions(+), 0 deletions(-)
> > > > > create mode 100644 drivers/scsi/storvsc_drv.c
> > > >
> > > > James, any objection to me applying this to the staging-next tree, and
> > > > at the same time, deleting this version of the driver from the
> > > > drivers/staging/hv/ directory?
> > >
> > > Well, yes, it has the same build failure as the previous one and that
> > > will make it non bisectable.
> >
> > Ah, that would make things a bit difficult, KY, please test your
> > patches...
>
> Greg,
>
> I pulled down your staging tree earlier today that had all the storvsc patches that you
> checked in yesterday, applied this patch and built it (successfully).
You're leaving remnants in staging.
Move the damn thing and pull the config options from staging when you
put them in SCSI.
James
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: KY Srinivasan @ 2012-02-09 20:43 UTC (permalink / raw)
To: Greg KH, James Bottomley
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org, ohering@suse.com,
hch@infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <20120209202409.GA22365@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Thursday, February 09, 2012 3:24 PM
> To: James Bottomley
> Cc: KY Srinivasan; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> scsi@vger.kernel.org
> Subject: Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the
> staging area
>
> On Thu, Feb 09, 2012 at 02:18:38PM -0600, James Bottomley wrote:
> > On Thu, 2012-02-09 at 12:04 -0800, Greg KH wrote:
> > > On Thu, Feb 09, 2012 at 12:04:11PM -0800, K. Y. Srinivasan wrote:
> > > > The storage driver (storvsc_drv.c) handles all block storage devices
> > > > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > > > staging tree for a while and this patch moves it out of the staging area.
> > > > As per Greg's recommendation, this patch makes no changes to the
> staging/hv
> > > > directory. Once the driver moves out of staging, we will cleanup the
> > > > staging/hv directory.
> > > >
> > > > James was willing to apply this patch during the 3.3-rc phase and a decision
> > > > was taken to defer this to 3.4 since Greg had queued up a bunch of storvsc
> > > > patches for 3.4. Now that Greg has applied all of the pending storvsc
> patches,
> > > > I am re-sending this patch to move this driver out of staging.
> > > >
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > ---
> > > > drivers/scsi/Kconfig | 7 +
> > > > drivers/scsi/Makefile | 3 +
> > > > drivers/scsi/storvsc_drv.c | 1548
> ++++++++++++++++++++++++++++++++++++++++++++
> > > > 3 files changed, 1558 insertions(+), 0 deletions(-)
> > > > create mode 100644 drivers/scsi/storvsc_drv.c
> > >
> > > James, any objection to me applying this to the staging-next tree, and
> > > at the same time, deleting this version of the driver from the
> > > drivers/staging/hv/ directory?
> >
> > Well, yes, it has the same build failure as the previous one and that
> > will make it non bisectable.
>
> Ah, that would make things a bit difficult, KY, please test your
> patches...
Greg,
I pulled down your staging tree earlier today that had all the storvsc patches that you
checked in yesterday, applied this patch and built it (successfully).
Regards,
K. Y
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: James Bottomley @ 2012-02-09 20:40 UTC (permalink / raw)
To: KY Srinivasan
Cc: Greg KH, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, hch@infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481B70CB0A@TK5EX14MBXC128.redmond.corp.microsoft.com>
On Thu, 2012-02-09 at 20:21 +0000, KY Srinivasan wrote:
>
> > -----Original Message-----
> > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> > Sent: Thursday, February 09, 2012 3:19 PM
> > To: Greg KH
> > Cc: KY Srinivasan; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > virtualization@lists.osdl.org; ohering@suse.com; hch@infradead.org; linux-
> > scsi@vger.kernel.org
> > Subject: Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the
> > staging area
> >
> > On Thu, 2012-02-09 at 12:04 -0800, Greg KH wrote:
> > > On Thu, Feb 09, 2012 at 12:04:11PM -0800, K. Y. Srinivasan wrote:
> > > > The storage driver (storvsc_drv.c) handles all block storage devices
> > > > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > > > staging tree for a while and this patch moves it out of the staging area.
> > > > As per Greg's recommendation, this patch makes no changes to the
> > staging/hv
> > > > directory. Once the driver moves out of staging, we will cleanup the
> > > > staging/hv directory.
> > > >
> > > > James was willing to apply this patch during the 3.3-rc phase and a decision
> > > > was taken to defer this to 3.4 since Greg had queued up a bunch of storvsc
> > > > patches for 3.4. Now that Greg has applied all of the pending storvsc patches,
> > > > I am re-sending this patch to move this driver out of staging.
> > > >
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > ---
> > > > drivers/scsi/Kconfig | 7 +
> > > > drivers/scsi/Makefile | 3 +
> > > > drivers/scsi/storvsc_drv.c | 1548
> > ++++++++++++++++++++++++++++++++++++++++++++
> > > > 3 files changed, 1558 insertions(+), 0 deletions(-)
> > > > create mode 100644 drivers/scsi/storvsc_drv.c
> > >
> > > James, any objection to me applying this to the staging-next tree, and
> > > at the same time, deleting this version of the driver from the
> > > drivers/staging/hv/ directory?
> >
> > Well, yes, it has the same build failure as the previous one and that
> > will make it non bisectable.
>
> James,
>
> What build failure is this. I just pulled down Greg's tree earlier today and applied this
> patch and built it.
This one
marc.info/?l=linux-driver-devel&m=132760187731205
James
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: Greg KH @ 2012-02-09 20:24 UTC (permalink / raw)
To: James Bottomley
Cc: K. Y. Srinivasan, linux-kernel, devel, virtualization, ohering,
hch, linux-scsi
In-Reply-To: <1328818718.2944.20.camel@dabdike.int.hansenpartnership.com>
On Thu, Feb 09, 2012 at 02:18:38PM -0600, James Bottomley wrote:
> On Thu, 2012-02-09 at 12:04 -0800, Greg KH wrote:
> > On Thu, Feb 09, 2012 at 12:04:11PM -0800, K. Y. Srinivasan wrote:
> > > The storage driver (storvsc_drv.c) handles all block storage devices
> > > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > > staging tree for a while and this patch moves it out of the staging area.
> > > As per Greg's recommendation, this patch makes no changes to the staging/hv
> > > directory. Once the driver moves out of staging, we will cleanup the
> > > staging/hv directory.
> > >
> > > James was willing to apply this patch during the 3.3-rc phase and a decision
> > > was taken to defer this to 3.4 since Greg had queued up a bunch of storvsc
> > > patches for 3.4. Now that Greg has applied all of the pending storvsc patches,
> > > I am re-sending this patch to move this driver out of staging.
> > >
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > ---
> > > drivers/scsi/Kconfig | 7 +
> > > drivers/scsi/Makefile | 3 +
> > > drivers/scsi/storvsc_drv.c | 1548 ++++++++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 1558 insertions(+), 0 deletions(-)
> > > create mode 100644 drivers/scsi/storvsc_drv.c
> >
> > James, any objection to me applying this to the staging-next tree, and
> > at the same time, deleting this version of the driver from the
> > drivers/staging/hv/ directory?
>
> Well, yes, it has the same build failure as the previous one and that
> will make it non bisectable.
Ah, that would make things a bit difficult, KY, please test your
patches...
^ 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