* [PATCH net-26 4/4] cxgb4vf: Use defined Mailbox Timeout
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
VF Driver should use mailbox command timeout specified in t4fw_interface.h
rather than hard-coded value of 500ms.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/t4vf_hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb4vf/t4vf_hw.c b/drivers/net/cxgb4vf/t4vf_hw.c
index 0f51c80..192db22 100644
--- a/drivers/net/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/cxgb4vf/t4vf_hw.c
@@ -171,7 +171,7 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void *cmd, int size,
delay_idx = 0;
ms = delay[0];
- for (i = 0; i < 500; i += ms) {
+ for (i = 0; i < FW_CMD_MAX_TIMEOUT; i += ms) {
if (sleep_ok) {
ms = delay[delay_idx];
if (delay_idx < ARRAY_SIZE(delay) - 1)
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-26 0/4] cxgb4vf: minor bug fixes -- revised patch set
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem
This is the same as the previous patch set but with the unacceptable patch
removed. Let me know if there's anything else I should do. Thanks and
sorry for not know the rules about that unacceptable patch.
[01/04]: Check driver parameters in the right place ...
[02/04]: Behave properly when CONFIG_DEBUG_FS isn't defined ...
[03/04]: Quiesce Virtual Interfaces on shutdown ...
[04/04]: Use defined Mailbox Timeout
drivers/net/cxgb4vf/cxgb4vf_main.c | 80 +++++++++++++++++++++++++++---------
drivers/net/cxgb4vf/t4vf_hw.c | 2 +-
2 files changed, 61 insertions(+), 21 deletions(-)
^ permalink raw reply
* [PATCH net-26 1/4] cxgb4vf: Check driver parameters in the right place ...
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
Check module parameter validity in the module initialization routine instead
of the PCI Device Probe routine.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index 56166ae..072b64e 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -2489,17 +2489,6 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
struct net_device *netdev;
/*
- * Vet our module parameters.
- */
- if (msi != MSI_MSIX && msi != MSI_MSI) {
- dev_err(&pdev->dev, "bad module parameter msi=%d; must be %d"
- " (MSI-X or MSI) or %d (MSI)\n", msi, MSI_MSIX,
- MSI_MSI);
- err = -EINVAL;
- goto err_out;
- }
-
- /*
* Print our driver banner the first time we're called to initialize a
* device.
*/
@@ -2802,7 +2791,6 @@ err_release_regions:
err_disable_device:
pci_disable_device(pdev);
-err_out:
return err;
}
@@ -2915,6 +2903,17 @@ static int __init cxgb4vf_module_init(void)
{
int ret;
+ /*
+ * Vet our module parameters.
+ */
+ if (msi != MSI_MSIX && msi != MSI_MSI) {
+ printk(KERN_WARNING KBUILD_MODNAME
+ ": bad module parameter msi=%d; must be %d"
+ " (MSI-X or MSI) or %d (MSI)\n",
+ msi, MSI_MSIX, MSI_MSI);
+ return -EINVAL;
+ }
+
/* Debugfs support is optional, just warn if this fails */
cxgb4vf_debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
if (!cxgb4vf_debugfs_root)
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-26 2/4] cxgb4vf: Behave properly when CONFIG_DEBUG_FS isn't defined ...
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
When CONFIG_DEBUG_FS we get "ERR_PTR()"s back from the debugfs routines
instead of NULL. Use the right predicates to check for this.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index 072b64e..2be1088 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -2040,7 +2040,7 @@ static int __devinit setup_debugfs(struct adapter *adapter)
{
int i;
- BUG_ON(adapter->debugfs_root == NULL);
+ BUG_ON(IS_ERR_OR_NULL(adapter->debugfs_root));
/*
* Debugfs support is best effort.
@@ -2061,7 +2061,7 @@ static int __devinit setup_debugfs(struct adapter *adapter)
*/
static void cleanup_debugfs(struct adapter *adapter)
{
- BUG_ON(adapter->debugfs_root == NULL);
+ BUG_ON(IS_ERR_OR_NULL(adapter->debugfs_root));
/*
* Unlike our sister routine cleanup_proc(), we don't need to remove
@@ -2700,11 +2700,11 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
/*
* Set up our debugfs entries.
*/
- if (cxgb4vf_debugfs_root) {
+ if (!IS_ERR_OR_NULL(cxgb4vf_debugfs_root)) {
adapter->debugfs_root =
debugfs_create_dir(pci_name(pdev),
cxgb4vf_debugfs_root);
- if (adapter->debugfs_root == NULL)
+ if (IS_ERR_OR_NULL(adapter->debugfs_root))
dev_warn(&pdev->dev, "could not create debugfs"
" directory");
else
@@ -2759,7 +2759,7 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
*/
err_free_debugfs:
- if (adapter->debugfs_root) {
+ if (!IS_ERR_OR_NULL(adapter->debugfs_root)) {
cleanup_debugfs(adapter);
debugfs_remove_recursive(adapter->debugfs_root);
}
@@ -2828,7 +2828,7 @@ static void __devexit cxgb4vf_pci_remove(struct pci_dev *pdev)
/*
* Tear down our debugfs entries.
*/
- if (adapter->debugfs_root) {
+ if (!IS_ERR_OR_NULL(adapter->debugfs_root)) {
cleanup_debugfs(adapter);
debugfs_remove_recursive(adapter->debugfs_root);
}
@@ -2916,12 +2916,12 @@ static int __init cxgb4vf_module_init(void)
/* Debugfs support is optional, just warn if this fails */
cxgb4vf_debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
- if (!cxgb4vf_debugfs_root)
+ if (IS_ERR_OR_NULL(cxgb4vf_debugfs_root))
printk(KERN_WARNING KBUILD_MODNAME ": could not create"
" debugfs entry, continuing\n");
ret = pci_register_driver(&cxgb4vf_driver);
- if (ret < 0)
+ if (ret < 0 && !IS_ERR_OR_NULL(cxgb4vf_debugfs_root))
debugfs_remove(cxgb4vf_debugfs_root);
return ret;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-26 3/4] cxgb4vf: Quiesce Virtual Interfaces on shutdown ...
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
When a Virtual Machine is rebooted, KVM currently fails to issue a Function
Level Reset against any "Attached PCI Devices" (AKA "PCI Passthrough"). In
addition to leaving the attached device in a random state in the next booted
kernel (which sort of violates the entire idea of a reboot reseting hardware
state), this leaves our peer thinking that the link is still up. (Note that
a bug has been filed with the KVM folks, #25332, but there's been no
response on that as of yet.) So, we add a "->shutdown()" method for the
Virtual Function PCI Device to handle administrative shutdowns like a
reboot.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 41 ++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index 2be1088..6aad64d 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -2862,6 +2862,46 @@ static void __devexit cxgb4vf_pci_remove(struct pci_dev *pdev)
}
/*
+ * "Shutdown" quiesce the device, stopping Ingress Packet and Interrupt
+ * delivery.
+ */
+static void __devexit cxgb4vf_pci_shutdown(struct pci_dev *pdev)
+{
+ struct adapter *adapter;
+ int pidx;
+
+ adapter = pci_get_drvdata(pdev);
+ if (!adapter)
+ return;
+
+ /*
+ * Disable all Virtual Interfaces. This will shut down the
+ * delivery of all ingress packets into the chip for these
+ * Virtual Interfaces.
+ */
+ for_each_port(adapter, pidx) {
+ struct net_device *netdev;
+ struct port_info *pi;
+
+ if (!test_bit(pidx, &adapter->registered_device_map))
+ continue;
+
+ netdev = adapter->port[pidx];
+ if (!netdev)
+ continue;
+
+ pi = netdev_priv(netdev);
+ t4vf_enable_vi(adapter, pi->viid, false, false);
+ }
+
+ /*
+ * Free up all Queues which will prevent further DMA and
+ * Interrupts allowing various internal pathways to drain.
+ */
+ t4vf_free_sge_resources(adapter);
+}
+
+/*
* PCI Device registration data structures.
*/
#define CH_DEVICE(devid, idx) \
@@ -2894,6 +2934,7 @@ static struct pci_driver cxgb4vf_driver = {
.id_table = cxgb4vf_pci_tbl,
.probe = cxgb4vf_pci_probe,
.remove = __devexit_p(cxgb4vf_pci_remove),
+ .shutdown = __devexit_p(cxgb4vf_pci_shutdown),
};
/*
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC PATCH V2 0/5] macvtap TX zero copy between guest and host kernel
From: Shirley Ma @ 2011-02-14 23:06 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Avi Kivity, Arnd Bergmann, xiaohui.xin, netdev, kvm, linux-kernel
In-Reply-To: <20110214130957.GA3128@redhat.com>
On Mon, 2011-02-14 at 15:09 +0200, Michael S. Tsirkin wrote:
> What's the status here? Since there are core net changes, we'll need
> to
> see the final version soon if it's to appear in 2.6.39.
I am updating the patch and retesting it for the new kernel. I am trying
to understand why zero copy patch caused small message size guest exits
doubled.
> Could the problem be related to the patch
> virtio_net: Add schedule check to napi_enable call
> ?
Not sure, I will retest w/i this patch.
> Also, I expect there should be driver patches for some
> devices? Where are they?
Yes, a NET_F_ZEROCOPY... flag is introduced for the device we we want to
support zero copy.
Thanks
Shirley
^ permalink raw reply
* Process for subsystem maintainers to get Hyper-V code out of staging.
From: Hank Janssen @ 2011-02-14 23:30 UTC (permalink / raw)
To: shemminger@linux-foundation.org, netdev@vger.kernel.org,
davem@davemloft.net, "linux-ide@vger.ke
Cc: KY Srinivasan, Hashir Abdi, Mike Sterling, Haiyang Zhang,
gregkh@suse.de
Stephen/James/David,
Greetings to you all. As you might be aware, we submitted Hyper-V drivers to the kernel 2009.
We have been extending these drivers with additional functionality and our primary focus
now is doing the work needed to exit the staging area.
To give you some background, the following are Hyper-V specific Linux drivers:
hv_vmbus The vmbus driver that is the bridge between guest and the
host
hv_storvsc The SCSI device driver
hv_blkvsc The IDE driver
hv_netvsc The network driver
We think our drivers are pretty close to be reviewed by the subsystem maintainers.
We have been working with Greg on hv_vmbus, and several other driver issues as it
relates to exiting staging. And now we are looking for guidance for the other drivers.
1. Most important thing of course, did we contact the correct subsystem
maintainers?
i. IDE/Blkvsc David Miller
ii. SCSI/Storvsc James Bottomley
iii. Network/Netvsc Stephen Hemminger
2. What is the process to submit the code for review?
3. Which mailing list(s) do we need to use for the code reviews
4. I assume normal patch format is required?
5. What additional information is needed
6. Once they leave staging where do they need to go? Because they all
pretty much come as a package we were thinking drivers/hyperv might
be a good place.
There are still a few outstanding items we are currently working on. But they should be
wrapped up shortly. (There are a few remaining FIXME comments in the code we are
cleaning up as I write this). But if possible we would like to get your feedback even as
we are addressing the issues we currently know about.
Thanks
Hank.
^ permalink raw reply
* RE: Process for subsystem maintainers to get Hyper-V code out of staging. - CORRECTED RECIPIENTS
From: Hank Janssen @ 2011-02-14 23:42 UTC (permalink / raw)
To: shemminger@linux-foundation.org, netdev@vger.kernel.org,
davem@davemloft.net, "linux-ide@vger.ke
Cc: KY Srinivasan, Hashir Abdi, Mike Sterling, Haiyang Zhang,
gregkh@suse.de
MY APOLOGIES-I made a typo on James email address. I corrected it and resend.
Sorry for the double email.
Stephen/James/David,
Greetings to you all. As you might be aware, we submitted Hyper-V drivers to the kernel 2009.
We have been extending these drivers with additional functionality and our primary focus now
is doing the work needed to exit the staging area.
To give you some background, the following are Hyper-V specific Linux drivers:
hv_vmbus The vmbus driver that is the bridge between guest and the
host
hv_storvsc The SCSI device driver
hv_blkvsc The IDE driver
hv_netvsc The network driver
We think our drivers are pretty close to be reviewed by the subsystem maintainers.
We have been working with Greg on hv_vmbus, and several other driver issues as it relates to
exiting staging. And now we are looking for guidance for the other drivers.
1. Most important thing of course, did we contact the correct subsystem
maintainers?
i. IDE/Blkvsc David Miller
ii. SCSI/Storvsc James Bottomley
iii. Network/Netvsc Stephen Hemminger
2. What is the process to submit the code for review?
3. Which mailing list(s) do we need to use for the code reviews
4. I assume normal patch format is required?
5. What additional information is needed
6. Once they leave staging where do they need to go? Because they all
pretty much come as a package we were thinking drivers/hyperv might
be a good place.
There are still a few outstanding items we are currently working on. But they should be
wrapped up shortly. (There are a few remaining FIXME comments in the code we are
cleaning up as I write this). But if possible we would like to get your feedback even
as we are addressing the issues we currently know about.
Thanks
Hank.
^ permalink raw reply
* Re: Process for subsystem maintainers to get Hyper-V code out of staging.
From: Greg KH @ 2011-02-14 23:45 UTC (permalink / raw)
To: Hank Janssen
Cc: shemminger@linux-foundation.org, netdev@vger.kernel.org,
davem@davemloft.net, linux-ide@vger.kernel.org,
Jame.Bottomley@HansenPartnership.com, linux-scsi@vger.kernel.org,
KY Srinivasan, Hashir Abdi, Mike Sterling, Haiyang Zhang
In-Reply-To: <8AFC7968D54FB448A30D8F38F259C56233F95737@TK5EX14MBXC114.redmond.corp.microsoft.com>
On Mon, Feb 14, 2011 at 11:30:07PM +0000, Hank Janssen wrote:
>
> Stephen/James/David,
>
> Greetings to you all. As you might be aware, we submitted Hyper-V drivers to the kernel 2009.
> We have been extending these drivers with additional functionality and our primary focus
> now is doing the work needed to exit the staging area.
>
> To give you some background, the following are Hyper-V specific Linux drivers:
>
> hv_vmbus The vmbus driver that is the bridge between guest and the
> host
> hv_storvsc The SCSI device driver
> hv_blkvsc The IDE driver
> hv_netvsc The network driver
>
> We think our drivers are pretty close to be reviewed by the subsystem maintainers.
>
> We have been working with Greg on hv_vmbus, and several other driver issues as it
> relates to exiting staging. And now we are looking for guidance for the other drivers.
>
> 1. Most important thing of course, did we contact the correct subsystem
> maintainers?
> i. IDE/Blkvsc David Miller
> ii. SCSI/Storvsc James Bottomley
> iii. Network/Netvsc Stephen Hemminger
That's what the MAINTAINERS file says, right?
> 2. What is the process to submit the code for review?
Like Documentation/SubmittingPatches shows, send patches.
> 3. Which mailing list(s) do we need to use for the code reviews
Again, MAINTAINERS shows this.
> 4. I assume normal patch format is required?
Yes.
> 5. What additional information is needed
What's normally needed.
> 6. Once they leave staging where do they need to go? Because they all
> pretty much come as a package we were thinking drivers/hyperv might
> be a good place.
That's up to the subsystem, if they want all network drivers in
drivers/net/ then they go there, same for scsi, it's up to the
maintainer.
> There are still a few outstanding items we are currently working on. But they should be
> wrapped up shortly. (There are a few remaining FIXME comments in the code we are
> cleaning up as I write this). But if possible we would like to get your feedback even as
> we are addressing the issues we currently know about.
I would wait and only ask for review _after_ you fix the things you know
about first. Otherwise it just wastes everyone's time.
thanks,
greg k-h
^ permalink raw reply
* Re: Process for subsystem maintainers to get Hyper-V code out of staging. - CORRECTED RECIPIENTS
From: Robert Hancock @ 2011-02-15 0:45 UTC (permalink / raw)
To: Hank Janssen
Cc: shemminger@linux-foundation.org, netdev@vger.kernel.org,
davem@davemloft.net, ide, KY Srinivasan, Hashir Abdi,
Mike Sterling, Haiyang Zhang, gregkh@suse.de" "
In-Reply-To: <8AFC7968D54FB448A30D8F38F259C56233F957D3@TK5EX14MBXC114.redmond.corp.microsoft.com>
On 02/14/2011 05:42 PM, Hank Janssen wrote:
>
> MY APOLOGIES-I made a typo on James email address. I corrected it and resend.
> Sorry for the double email.
>
>
> Stephen/James/David,
>
> Greetings to you all. As you might be aware, we submitted Hyper-V drivers to the kernel 2009.
> We have been extending these drivers with additional functionality and our primary focus now
> is doing the work needed to exit the staging area.
>
> To give you some background, the following are Hyper-V specific Linux drivers:
>
> hv_vmbus The vmbus driver that is the bridge between guest and the
> host
> hv_storvsc The SCSI device driver
> hv_blkvsc The IDE driver
Given that the IDE subsystem (drivers/ide) is currently in
maintenance-only mode, and isn't used by modern distributions, you
likely want to make this a libata driver instead.
Though, from what's in current git, it's not clear to me what the HV IDE
(and SCSI) drivers are attempting to do. Is it really something that
looks like an IDE controller from the guest OS point of view? If not,
then having it as an IDE driver would be the wrong thing to do, it
should be more of a generic block driver. In that case, then, why are
there both SCSI and IDE drivers in the first place?
> hv_netvsc The network driver
>
> We think our drivers are pretty close to be reviewed by the subsystem maintainers.
>
> We have been working with Greg on hv_vmbus, and several other driver issues as it relates to
> exiting staging. And now we are looking for guidance for the other drivers.
>
> 1. Most important thing of course, did we contact the correct subsystem
> maintainers?
> i. IDE/Blkvsc David Miller
> ii. SCSI/Storvsc James Bottomley
> iii. Network/Netvsc Stephen Hemminger
> 2. What is the process to submit the code for review?
> 3. Which mailing list(s) do we need to use for the code reviews
> 4. I assume normal patch format is required?
> 5. What additional information is needed
> 6. Once they leave staging where do they need to go? Because they all
> pretty much come as a package we were thinking drivers/hyperv might
> be a good place.
>
> There are still a few outstanding items we are currently working on. But they should be
> wrapped up shortly. (There are a few remaining FIXME comments in the code we are
> cleaning up as I write this). But if possible we would like to get your feedback even
> as we are addressing the issues we currently know about.
>
> Thanks
>
> Hank.
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" 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
* (unknown),
From: Western Union Transfer @ 2011-02-14 23:21 UTC (permalink / raw)
We have been trying to reach you since the past few days,
as my associate has helped me to send your first payment
of $7,500 USD to you as instructed by Mr. David Cameron
the United Kingdom prime minister after the last G20
meeting that was held in United Kingdom, making you one
of the beneficiaries. Here is the information below.
MONEY TRANSFER CONTROL NUMBER: 3928738492
SENDER NAME:Solomon Daniel
AMOUNT: $7,500 USD
I told him to keep sending you $7,500 USD twice a week
until the FULL payment of ($360.000 United State Dollars)
is completed.
Note a certificate will be made to change the Receiver Name as
stated by the British prime minister, send your Full Names
and your direct phone contact via Email to: Mr Gary Moore
The money will not reflect until the clearance certificate is
issue to you by the G20 committee.
contact Mr. Gary Moore for your clearance certificate.
Mr Gary Moore
E-mail:western_uniontransfer09@zbavitu.net
D/L:+44 7024018331
^ permalink raw reply
* Re: [PATCH net-26 0/4] cxgb4vf: minor bug fixes -- revised patch set
From: David Miller @ 2011-02-15 1:37 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Mon, 14 Feb 2011 14:56:21 -0800
> [01/04]: Check driver parameters in the right place ...
> [02/04]: Behave properly when CONFIG_DEBUG_FS isn't defined ...
> [03/04]: Quiesce Virtual Interfaces on shutdown ...
> [04/04]: Use defined Mailbox Timeout
All applied, thanks.
^ permalink raw reply
* Re: [PATCH] phy/micrel: add ability to support 50MHz RMII clock on KZS8051RNL
From: David Miller @ 2011-02-15 1:38 UTC (permalink / raw)
To: baruch; +Cc: netdev, david.choi
In-Reply-To: <e426eef4b15c4e1c77981094c3c8020012aaca42.1297685030.git.baruch@tkos.co.il>
From: Baruch Siach <baruch@tkos.co.il>
Date: Mon, 14 Feb 2011 14:05:33 +0200
> Platform code can now set the MICREL_PHY_50MHZ_CLK bit of dev_flags in a fixup
> routine (registered with phy_register_fixup_for_uid()), to make the KZS8051RNL
> PHY work with 50MHz RMII reference clock.
>
> Cc: David J. Choi <david.choi@micrel.com>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] arp_notify: unconditionally send gratuitous ARP for NETDEV_NOTIFY_PEERS.
From: David Miller @ 2011-02-15 1:46 UTC (permalink / raw)
To: ian.campbell; +Cc: netdev
In-Reply-To: <1297446256-23917-1-git-send-email-ian.campbell@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 11 Feb 2011 17:44:16 +0000
> NETDEV_NOTIFY_PEER is an explicit request by the driver to send a link
> notification while NETDEV_UP/NETDEV_CHANGEADDR generate link
> notifications as a sort of side effect.
>
> In the later cases the sysctl option is present because link
> notification events can have undesired effects e.g. if the link is
> flapping. I don't think this applies in the case of an explicit
> request from a driver.
>
> This patch makes NETDEV_NOTIFY_PEER unconditional, if preferred we
> could add a new sysctl for this case which defaults to on.
>
> This change causes Xen post-migration ARP notifications (which cause
> switches to relearn their MAC tables etc) to be sent by default.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Ok, applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: provide capability and group sets via SCM
From: David Miller @ 2011-02-15 1:49 UTC (permalink / raw)
To: casey
Cc: linux-kernel, netdev, ext-jarkko.2.sakkinen, Janne.Karhunen,
elena.reshetova
In-Reply-To: <4D51C38B.1060902@schaufler-ca.com>
From: Casey Schaufler <casey@schaufler-ca.com>
Date: Tue, 08 Feb 2011 14:28:27 -0800
>
> Subject: [PATCH] net: provide group lists and capability set via CMSG
>
> Provide the namespace converted group list of the peer
> process using the SCM mechanism. Provide the capability
> set of the peer process. The capability set is not
> namespace converted on the assumption that there is no
> such conversion available or required.
>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
You can't just hit the asm-generic header, you have to also hit
all of the architectures that don't use the asm-generic header,
including sparc, powerpc, mips, s390, arm, alpha, cris, frv, h8300,
ia64, m32r, m68k, m68knommu, mn10300, parisc, and xtensa.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Cache PMTU/redirects in inetpeer
From: David Miller @ 2011-02-15 5:46 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110210.150957.115925131.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 10 Feb 2011 15:09:57 -0800 (PST)
> From: David Miller <davem@davemloft.net>
> Date: Wed, 09 Feb 2011 22:12:49 -0800 (PST)
>
>> This is what I've been working on for the past several days.
>
> Just FYI I've pushed just the infrastructure bits (patches 1, 2,
> and 3) into net-next-2.6 since those have no side effects.
>
> I won't push the other two until I can do some good testing on
> them.
I've now pushed the final two patches from the original series
into net-next-2.6
Please if anyone runs into troubles, give a good bug report and I
will fix the problems as quickly as possible.
Thanks!
^ permalink raw reply
* Re: [Bugme-new] [Bug 27212] New: Warning kmemcheck: Caught 64-bit read from uninitialized memory in netlink_broadcast_filtered
From: Pekka Enberg @ 2011-02-15 5:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon,
casteyde.christian, Changli Gao, Vegard Nossum, David Miller,
linux-kernel, Christoph Lameter, David Rientjes
In-Reply-To: <1297704922.2996.60.camel@edumazet-laptop>
On Mon, Feb 14, 2011 at 7:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 21 janvier 2011 à 09:49 +0200, Pekka Enberg a écrit :
>
>> It actually looks like a bug in SLUB+kmemcheck. The
>> kmemcheck_slab_alloc() call in slab_post_alloc_hook() should use ksize()
>> instead of s->objsize. SLAB seems to do the right thing already. Anyone
>> care to send a patch my way?
>>
>
> Hmm, what do you think of following patch ?
>
> Thanks, and sorry for the delay.
Looks good to me. Christoph, David, any objections to the patch?
> [PATCH] slub: fix kmemcheck calls to match ksize() hints
>
> Recent use of ksize() in network stack (commit ca44ac38 : net: don't
> reallocate skb->head unless the current one hasn't the needed extra size
> or is shared) triggers kmemcheck warnings, because ksize() can return
> more space than kmemcheck is aware of.
>
> Pekka Enberg noticed SLAB+kmemcheck is doing the right thing, while SLUB
> +kmemcheck doesnt.
>
> Bugzilla reference #27212
>
> Reported-by: Christian Casteyde <casteyde.christian@free.fr>
> Suggested-by: Pekka Enberg <penberg@kernel.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: David Miller <davem@davemloft.net>
> CC: Changli Gao <xiaosuo@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> ---
> mm/slub.c | 49 ++++++++++++++++++++++++++-----------------------
> 1 file changed, 26 insertions(+), 23 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index e15aa7f..ee0aeb8 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -797,10 +797,34 @@ static inline int slab_pre_alloc_hook(struct kmem_cache *s, gfp_t flags)
> return should_failslab(s->objsize, flags, s->flags);
> }
>
> +static inline size_t slab_ksize(const struct kmem_cache *s)
> +{
> +#ifdef CONFIG_SLUB_DEBUG
> + /*
> + * Debugging requires use of the padding between object
> + * and whatever may come after it.
> + */
> + if (s->flags & (SLAB_RED_ZONE | SLAB_POISON))
> + return s->objsize;
> +
> +#endif
> + /*
> + * If we have the need to store the freelist pointer
> + * back there or track user information then we can
> + * only use the space before that information.
> + */
> + if (s->flags & (SLAB_DESTROY_BY_RCU | SLAB_STORE_USER))
> + return s->inuse;
> + /*
> + * Else we can use all the padding etc for the allocation
> + */
> + return s->size;
> +}
> +
> static inline void slab_post_alloc_hook(struct kmem_cache *s, gfp_t flags, void *object)
> {
> flags &= gfp_allowed_mask;
> - kmemcheck_slab_alloc(s, flags, object, s->objsize);
> + kmemcheck_slab_alloc(s, flags, object, slab_ksize(s));
> kmemleak_alloc_recursive(object, s->objsize, 1, s->flags, flags);
> }
>
> @@ -2696,7 +2720,6 @@ EXPORT_SYMBOL(__kmalloc_node);
> size_t ksize(const void *object)
> {
> struct page *page;
> - struct kmem_cache *s;
>
> if (unlikely(object == ZERO_SIZE_PTR))
> return 0;
> @@ -2707,28 +2730,8 @@ size_t ksize(const void *object)
> WARN_ON(!PageCompound(page));
> return PAGE_SIZE << compound_order(page);
> }
> - s = page->slab;
>
> -#ifdef CONFIG_SLUB_DEBUG
> - /*
> - * Debugging requires use of the padding between object
> - * and whatever may come after it.
> - */
> - if (s->flags & (SLAB_RED_ZONE | SLAB_POISON))
> - return s->objsize;
> -
> -#endif
> - /*
> - * If we have the need to store the freelist pointer
> - * back there or track user information then we can
> - * only use the space before that information.
> - */
> - if (s->flags & (SLAB_DESTROY_BY_RCU | SLAB_STORE_USER))
> - return s->inuse;
> - /*
> - * Else we can use all the padding etc for the allocation
> - */
> - return s->size;
> + return slab_ksize(page->slab);
> }
> EXPORT_SYMBOL(ksize);
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* FINANCIAL LENDER
From: ZENITH HOME LENDER INC. @ 2011-02-15 6:40 UTC (permalink / raw)
To: zenithhlinc
apply for a financial lending amount to start your business our interest is very affordable
our lending process is very fast as well as percentage rate of 2.5% yearly from $5 000.00
min To $100 000 000.00 max
get back to us on this information below
amount, duration time,address and phone number
regards,
zenith home lender inc
zenithhlinc@gmail.com
mr ronald.c. foster
^ permalink raw reply
* [PATCH v2 3/5] omap: panda: add fixed regulator device for wlan
From: Panduranga Mallireddy @ 2011-02-15 8:40 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
In-Reply-To: <1297759236-25323-3-git-send-email-panduranga_mallireddy@ti.com>
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Based on the patch for zoom by Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/board-omap4panda.c | 34 ++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index cc9df6c..cd25255 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -26,6 +26,7 @@
#include <linux/usb/otg.h>
#include <linux/i2c/twl.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
#include <mach/hardware.h>
#include <mach/omap4-common.h>
@@ -45,6 +46,7 @@
#define GPIO_HUB_POWER 1
#define GPIO_HUB_NRESET 62
+#define GPIO_WIFI_PMENA 43
static struct gpio_led gpio_leds[] = {
{
@@ -172,6 +174,37 @@ static struct regulator_consumer_supply omap4_panda_vmmc_supply[] = {
},
};
+static struct regulator_consumer_supply omap4_panda_vmmc5_supply = {
+ .supply = "vmmc",
+ .dev_name = "mmci-omap-hs.4",
+};
+
+static struct regulator_init_data panda_vmmc5 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &omap4_panda_vmmc5_supply,
+};
+
+static struct fixed_voltage_config panda_vwlan = {
+ .supply_name = "vwl1271",
+ .microvolts = 1800000, /* 1.8V */
+ .gpio = GPIO_WIFI_PMENA,
+ .startup_delay = 70000, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = &panda_vmmc5,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &panda_vwlan,
+ },
+};
+
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
@@ -430,6 +463,7 @@ static void __init omap4_panda_init(void)
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
+ platform_device_register(&omap_vwlan_device);
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 Panda uses internal transceiver so register nop transceiver */
--
1.5.6.3
^ permalink raw reply related
* [PATCH v2 0/5] Panda: Support for WLAN on WL127x
From: Panduranga Mallireddy @ 2011-02-15 8:40 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
Fixes from V1:
1. Removing the pull up of WLAN IRQ line, since it is always held up by wl127x device.
Adding support for WLAN on Panda board using wl12xx and mac80211 drivers
Patches were tested on Panda board.
These patches add software control for emulating card detect events,
add board configurations to support the wl127x device.
These patches are dependent on the patches that enable clock for WLAN on panda.
Please refer the following links for these patches:
https://patchwork.kernel.org/patch/546381/
https://patchwork.kernel.org/patch/546401/
[PATCH 5/5] OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platforms
is dependent on hwmod adpotation for HSMMC patches series.
For original patches of adpotation for HSMMC refer:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43464.html
Patches are based on mainline 2.6.38-rc3
Kishore Kadiyala (1):
OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platforms
Panduranga Mallireddy (4):
omap: panda: wlan board muxing
omap: select REGULATOR_FIXED_VOLTAGE by default for panda and sdp4430
omap: panda: add fixed regulator device for wlan
omap: panda: add mmc5/wl1271 device support
arch/arm/mach-omap2/Kconfig | 2 +
arch/arm/mach-omap2/board-omap4panda.c | 67 ++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/hsmmc.c | 5 ++
drivers/mmc/host/omap_hsmmc.c | 24 +++++++++--
4 files changed, 94 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH v2 1/5] omap: panda: wlan board muxing
From: Panduranga Mallireddy @ 2011-02-15 8:40 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
In-Reply-To: <1297759236-25323-1-git-send-email-panduranga_mallireddy@ti.com>
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc5 (fifth mmc controller) on the PANDA.
Based on the wlan board muxing for zoom3 by Ohad Ben-Cohen
<ohadb@ti.com>
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/board-omap4panda.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 9218862..cc9df6c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -401,6 +401,19 @@ static int __init omap4_panda_i2c_init(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* WLAN IRQ - GPIO 53 */
+ OMAP4_MUX(GPMC_NCS3, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ /* WLAN POWER ENABLE - GPIO 43 */
+ OMAP4_MUX(GPMC_A19, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC5 CMD */
+ OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC5 CLK */
+ OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC5 DAT[0-3] */
+ OMAP4_MUX(SDMMC5_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(SDMMC5_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(SDMMC5_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(SDMMC5_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.5.6.3
^ permalink raw reply related
* [PATCH v2 2/5] omap: select REGULATOR_FIXED_VOLTAGE by default for panda and sdp4430
From: Panduranga Mallireddy @ 2011-02-15 8:40 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
In-Reply-To: <1297759236-25323-2-git-send-email-panduranga_mallireddy@ti.com>
Power to the wl12xx wlan device is controlled by a fixed regulator.
Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE.
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1a2cf62..eeaeb3b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -300,6 +300,7 @@ config MACH_OMAP_4430SDP
depends on ARCH_OMAP4
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
+ select REGULATOR_FIXED_VOLTAGE
config MACH_OMAP4_PANDA
bool "OMAP4 Panda Board"
@@ -307,6 +308,7 @@ config MACH_OMAP4_PANDA
depends on ARCH_OMAP4
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
+ select REGULATOR_FIXED_VOLTAGE
config OMAP3_EMU
bool "OMAP3 debugging peripherals"
--
1.5.6.3
^ permalink raw reply related
* [PATCH v2 4/5] omap: panda: add mmc5/wl1271 device support
From: Panduranga Mallireddy @ 2011-02-15 8:40 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
In-Reply-To: <1297759236-25323-4-git-send-email-panduranga_mallireddy@ti.com>
Add MMC5 support on PANDA, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Based on the patch for mmc3/wl1271 device support for zoom by Ohad
Ben-Cohen <ohad@wizery.com>
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/board-omap4panda.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index cd25255..ef43010 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -27,6 +27,7 @@
#include <linux/i2c/twl.h>
#include <linux/regulator/machine.h>
#include <linux/regulator/fixed.h>
+#include <linux/wl12xx.h>
#include <mach/hardware.h>
#include <mach/omap4-common.h>
@@ -47,6 +48,7 @@
#define GPIO_HUB_POWER 1
#define GPIO_HUB_NRESET 62
#define GPIO_WIFI_PMENA 43
+#define GPIO_WIFI_IRQ 53
static struct gpio_led gpio_leds[] = {
{
@@ -164,6 +166,15 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_wp = -EINVAL,
.gpio_cd = -EINVAL,
},
+ {
+ .name = "wl1271",
+ .mmc = 5,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
+ .gpio_wp = -EINVAL,
+ .gpio_cd = -EINVAL,
+ .ocr_mask = MMC_VDD_165_195,
+ .nonremovable = true,
+ },
{} /* Terminator */
};
@@ -205,6 +216,12 @@ static struct platform_device omap_vwlan_device = {
},
};
+struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
+ .irq = OMAP_GPIO_IRQ(GPIO_WIFI_IRQ),
+ /* PANDA ref clock is 38.4 MHz */
+ .board_ref_clock = 2,
+};
+
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
@@ -461,6 +478,9 @@ static void __init omap4_panda_init(void)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, package);
+ if (wl12xx_set_platform_data(&omap_panda_wlan_data))
+ pr_err("error setting wl12xx data\n");
+
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
platform_device_register(&omap_vwlan_device);
--
1.5.6.3
^ permalink raw reply related
* [PATCH v2 5/5] OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platforms
From: Panduranga Mallireddy @ 2011-02-15 8:40 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Kishore Kadiyala,
Panduranga Mallireddy
In-Reply-To: <1297759236-25323-5-git-send-email-panduranga_mallireddy@ti.com>
From: Kishore Kadiyala <kishore.kadiyala@ti.com>
OMAP4 supports up to 5 MMC controllers, but only 3 of these were
initialized. MMC5 is used by wl12xx chip. So initialize MMC4 and MMC5.
Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com>
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/hsmmc.c | 5 +++++
drivers/mmc/host/omap_hsmmc.c | 24 ++++++++++++++++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 8f1a484..3c0809f 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -348,6 +348,11 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
mmc->slots[0].after_set_reg = NULL;
}
break;
+ case 4:
+ case 5:
+ mmc->slots[0].before_set_reg = NULL;
+ mmc->slots[0].after_set_reg = NULL;
+ break;
default:
pr_err("MMC%d configuration not supported!\n", c->mmc);
kfree(mmc);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f59f8da..2525071 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -260,7 +260,7 @@ static int omap_hsmmc_1_set_power(struct device *dev, int slot, int power_on,
return ret;
}
-static int omap_hsmmc_23_set_power(struct device *dev, int slot, int power_on,
+static int omap_hsmmc_235_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
struct omap_hsmmc_host *host =
@@ -316,6 +316,12 @@ static int omap_hsmmc_23_set_power(struct device *dev, int slot, int power_on,
return ret;
}
+static int omap_hsmmc_4_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ return 0;
+}
+
static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
@@ -326,7 +332,7 @@ static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
return regulator_set_mode(host->vcc, mode);
}
-static int omap_hsmmc_23_set_sleep(struct device *dev, int slot, int sleep,
+static int omap_hsmmc_235_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
struct omap_hsmmc_host *host =
@@ -365,6 +371,12 @@ static int omap_hsmmc_23_set_sleep(struct device *dev, int slot, int sleep,
return regulator_enable(host->vcc_aux);
}
+static int omap_hsmmc_4_set_sleep(struct device *dev, int slot, int sleep,
+ int vdd, int cardsleep)
+{
+ return 0;
+}
+
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
struct regulator *reg;
@@ -379,10 +391,14 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
break;
case OMAP_MMC2_DEVID:
case OMAP_MMC3_DEVID:
+ case OMAP_MMC5_DEVID:
/* Off-chip level shifting, or none */
- mmc_slot(host).set_power = omap_hsmmc_23_set_power;
- mmc_slot(host).set_sleep = omap_hsmmc_23_set_sleep;
+ mmc_slot(host).set_power = omap_hsmmc_235_set_power;
+ mmc_slot(host).set_sleep = omap_hsmmc_235_set_sleep;
break;
+ case OMAP_MMC4_DEVID:
+ mmc_slot(host).set_power = omap_hsmmc_4_set_power;
+ mmc_slot(host).set_sleep = omap_hsmmc_4_set_sleep;
default:
pr_err("MMC%d configuration not supported!\n", host->id);
return -EINVAL;
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH 02/14] net/fec: release mem_region requested in probe in error path and remove
From: Uwe Kleine-König @ 2011-02-15 8:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shawn.guo, kernel
In-Reply-To: <20110214.110549.193710827.davem@davemloft.net>
Hi David,
On Mon, Feb 14, 2011 at 11:05:49AM -0800, David Miller wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Date: Mon, 14 Feb 2011 09:25:25 +0100
> > On Sun, Feb 13, 2011 at 01:15:31PM -0800, David Miller wrote:
> >> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >> Date: Sun, 13 Feb 2011 22:07:09 +0100
> >> > On Fri, Feb 11, 2011 at 09:25:32PM -0800, David Miller wrote:
> >> >> I can't pull from that tree because it is _NOT_ based upon net-next-2.6
> >> >> and therefore brings in all kinds of commits not related to your work.
> >> > Sorry, I'm not used to the customs on netdev. I can rebase, but still I
> >> > wonder about the reason you cannot pull for. The only reason I can
> >> > imagine is that you fear unrelated breakage when taking these patches
> >> > that are already in Linus' tree. But if it's that, wouldn't it be great
> >> > the realize this breakage already now and not only during the next merge
> >> > window?
> >>
> >> My trees only merge in Linus's tree when absolutely necessary,
> >> to resolve conflicts or similar.
> > You don't merge Linus' tree, you merge mine that just happen to be based
> > on a newer version of Linus' tree. I'm sure Linus won't yell on you for
> > that. He only objects to merge directly from his tree, because the
> > result for him is an "empty" merge.
>
> You don't get it.
>
> These merge commits look ugly and Linus wants them minimized.
Hmm, right, I don't get why this looks uglier for Linus than a merge of
a tree that bases on something you already have. I guess you're too
annoyed by now to explain why you think it does.
> Either you follow the rules and my expectations, which is that when you
> give me a GIT tree to pull from it's based upon one of my trees, or
> I don't pull from you.
So I rebased my tree on something older. It now starts at
c69b909 (pch_can: fix module reload issue with MSI)
which is already in net-next/master.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ 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