* [patch 2/2 v2] qlcnic: using too much stack
From: Dan Carpenter @ 2010-08-10 7:49 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: Anirban Chakraborty, linux-driver, David S. Miller,
Sucheta Chakraborty, netdev, kernel-janitors
qlcnic_pci_info structs are 128 bytes so an array of 8 uses 1024 bytes.
That's a lot if you run with 4K stacks. I allocated them with kcalloc()
instead.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
V2: No change. I had to respin because of the 1/1 patch.
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 6b8df55..bf6d87a 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -473,14 +473,20 @@ qlcnic_cleanup_pci_map(struct qlcnic_adapter *adapter)
static int
qlcnic_init_pci_info(struct qlcnic_adapter *adapter)
{
- struct qlcnic_pci_info pci_info[QLCNIC_MAX_PCI_FUNC];
+ struct qlcnic_pci_info *pci_info;
int i, ret = 0, err;
u8 pfn;
+ pci_info = kcalloc(QLCNIC_MAX_PCI_FUNC, sizeof(*pci_info), GFP_KERNEL);
+ if (!pci_info)
+ return -ENOMEM;
+
adapter->npars = kzalloc(sizeof(struct qlcnic_npar_info) *
QLCNIC_MAX_PCI_FUNC, GFP_KERNEL);
- if (!adapter->npars)
- return -ENOMEM;
+ if (!adapter->npars) {
+ err = -ENOMEM;
+ goto err_pci_info;
+ }
adapter->eswitch = kzalloc(sizeof(struct qlcnic_eswitch) *
QLCNIC_NIU_MAX_XG_PORTS, GFP_KERNEL);
@@ -508,6 +514,7 @@ qlcnic_init_pci_info(struct qlcnic_adapter *adapter)
for (i = 0; i < QLCNIC_NIU_MAX_XG_PORTS; i++)
adapter->eswitch[i].flags |= QLCNIC_SWITCH_ENABLE;
+ kfree(pci_info);
return 0;
err_eswitch:
@@ -516,6 +523,8 @@ err_eswitch:
err_npars:
kfree(adapter->npars);
adapter->npars = NULL;
+err_pci_info:
+ kfree(pci_info);
return ret;
}
@@ -3362,15 +3371,21 @@ qlcnic_sysfs_read_pci_config(struct file *file, struct kobject *kobj,
struct device *dev = container_of(kobj, struct device, kobj);
struct qlcnic_adapter *adapter = dev_get_drvdata(dev);
struct qlcnic_pci_func_cfg pci_cfg[QLCNIC_MAX_PCI_FUNC];
- struct qlcnic_pci_info pci_info[QLCNIC_MAX_PCI_FUNC];
+ struct qlcnic_pci_info *pci_info;
int i, ret;
if (size != sizeof(pci_cfg))
return QL_STATUS_INVALID_PARAM;
+ pci_info = kcalloc(QLCNIC_MAX_PCI_FUNC, sizeof(*pci_info), GFP_KERNEL);
+ if (!pci_info)
+ return -ENOMEM;
+
ret = qlcnic_get_pci_info(adapter, pci_info);
- if (ret)
+ if (ret) {
+ kfree(pci_info);
return ret;
+ }
for (i = 0; i < QLCNIC_MAX_PCI_FUNC ; i++) {
pci_cfg[i].pci_func = pci_info[i].id;
@@ -3381,8 +3396,8 @@ qlcnic_sysfs_read_pci_config(struct file *file, struct kobject *kobj,
memcpy(&pci_cfg[i].def_mac_addr, &pci_info[i].mac, ETH_ALEN);
}
memcpy(buf, &pci_cfg, size);
+ kfree(pci_info);
return size;
-
}
static struct bin_attribute bin_attr_npar_config = {
.attr = {.name = "npar_config", .mode = (S_IRUGO | S_IWUSR)},
^ permalink raw reply related
* [patch 1/2 v2] qlcnic: clean up qlcnic_init_pci_info()
From: Dan Carpenter @ 2010-08-10 7:47 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: Anirban Chakraborty, linux-driver, David S. Miller,
Sucheta Chakraborty, netdev, kernel-janitors
In the original code we allocated memory conditionally and freed it in
the error handling unconditionally. It turns out that this function is
only called during initialization and "adapter->npars" and
"adapter->eswitch" are always NULL at the start of the function. I
removed those checks.
Also since I was cleaning things, I changed the error handling for
qlcnic_get_pci_info() and pulled everything in an indent level.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
V2: fixed a typo. I set eswitch to NULL twice instead of npars by
mistake.
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index b9615bd..6b8df55 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -477,44 +477,45 @@ qlcnic_init_pci_info(struct qlcnic_adapter *adapter)
int i, ret = 0, err;
u8 pfn;
- if (!adapter->npars)
- adapter->npars = kzalloc(sizeof(struct qlcnic_npar_info) *
+ adapter->npars = kzalloc(sizeof(struct qlcnic_npar_info) *
QLCNIC_MAX_PCI_FUNC, GFP_KERNEL);
if (!adapter->npars)
return -ENOMEM;
- if (!adapter->eswitch)
- adapter->eswitch = kzalloc(sizeof(struct qlcnic_eswitch) *
+ adapter->eswitch = kzalloc(sizeof(struct qlcnic_eswitch) *
QLCNIC_NIU_MAX_XG_PORTS, GFP_KERNEL);
if (!adapter->eswitch) {
err = -ENOMEM;
- goto err_eswitch;
+ goto err_npars;
}
ret = qlcnic_get_pci_info(adapter, pci_info);
- if (!ret) {
- for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++) {
- pfn = pci_info[i].id;
- if (pfn > QLCNIC_MAX_PCI_FUNC)
- return QL_STATUS_INVALID_PARAM;
- adapter->npars[pfn].active = pci_info[i].active;
- adapter->npars[pfn].type = pci_info[i].type;
- adapter->npars[pfn].phy_port = pci_info[i].default_port;
- adapter->npars[pfn].mac_learning = DEFAULT_MAC_LEARN;
- adapter->npars[pfn].min_bw = pci_info[i].tx_min_bw;
- adapter->npars[pfn].max_bw = pci_info[i].tx_max_bw;
- }
-
- for (i = 0; i < QLCNIC_NIU_MAX_XG_PORTS; i++)
- adapter->eswitch[i].flags |= QLCNIC_SWITCH_ENABLE;
+ if (ret)
+ goto err_eswitch;
- return ret;
+ for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++) {
+ pfn = pci_info[i].id;
+ if (pfn > QLCNIC_MAX_PCI_FUNC)
+ return QL_STATUS_INVALID_PARAM;
+ adapter->npars[pfn].active = pci_info[i].active;
+ adapter->npars[pfn].type = pci_info[i].type;
+ adapter->npars[pfn].phy_port = pci_info[i].default_port;
+ adapter->npars[pfn].mac_learning = DEFAULT_MAC_LEARN;
+ adapter->npars[pfn].min_bw = pci_info[i].tx_min_bw;
+ adapter->npars[pfn].max_bw = pci_info[i].tx_max_bw;
}
+ for (i = 0; i < QLCNIC_NIU_MAX_XG_PORTS; i++)
+ adapter->eswitch[i].flags |= QLCNIC_SWITCH_ENABLE;
+
+ return 0;
+
+err_eswitch:
kfree(adapter->eswitch);
adapter->eswitch = NULL;
-err_eswitch:
+err_npars:
kfree(adapter->npars);
+ adapter->npars = NULL;
return ret;
}
^ permalink raw reply related
* Re: [PATCH] usbnet: rx_submit() should return an error code.
From: Oliver Neukum @ 2010-08-10 7:42 UTC (permalink / raw)
To: David Miller
Cc: ellyjones-hpIqsD4AKlfQT0dZR+AlfA,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
jglasgow-hpIqsD4AKlfQT0dZR+AlfA
In-Reply-To: <20100810.001855.179947437.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Am Dienstag, 10. August 2010, 09:18:55 schrieb David Miller:
> From: Elly Jones <ellyjones-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Date: Mon, 9 Aug 2010 18:37:50 -0400
>
> > This patch makes rx_submit() return an error code, and makes some call sites
> > that care check the return value. This is important because it lets us properly
> > handle cases where the device isn't ready to handle URB submissions (e.g., when
> > it is autosuspended under some drivers); previously, we would attempt and fail
> > to submit URBs and reschedule ourselves to try and fail again. This patch is
> > against Linus's 2.6 repo commit 45d7f32c7a43cbb9592886d38190e379e2eb2226.
> >
> > Signed-Off-By: Elizabeth Jones <ellyjones-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>
> What gets kevent() running again to run the rx_submit() calls when the
> device comes back from being suspended?
>
usbnet_resume() schedules usbnet_bh() which will take care of that.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] usbnet: rx_submit() should return an error code.
From: David Miller @ 2010-08-10 7:18 UTC (permalink / raw)
To: ellyjones; +Cc: oneukum, stern, netdev, linux-usb, jglasgow
In-Reply-To: <AANLkTimubaXzLjROeaNB0dV09thKfpLDyaEA-t_yzyV1@mail.gmail.com>
From: Elly Jones <ellyjones@google.com>
Date: Mon, 9 Aug 2010 18:37:50 -0400
> This patch makes rx_submit() return an error code, and makes some call sites
> that care check the return value. This is important because it lets us properly
> handle cases where the device isn't ready to handle URB submissions (e.g., when
> it is autosuspended under some drivers); previously, we would attempt and fail
> to submit URBs and reschedule ourselves to try and fail again. This patch is
> against Linus's 2.6 repo commit 45d7f32c7a43cbb9592886d38190e379e2eb2226.
>
> Signed-Off-By: Elizabeth Jones <ellyjones@google.com>
What gets kevent() running again to run the rx_submit() calls when the
device comes back from being suspended?
^ permalink raw reply
* Re: [PATCH 3/3] phy.c: fix kernel-doc warnings
From: David Miller @ 2010-08-10 7:09 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev
In-Reply-To: <20100809164159.c81cd1c4.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 9 Aug 2010 16:41:59 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix phy.c kernel-doc notation:
>
> Warning(drivers/net/phy/phy.c:313): No description found for parameter 'ifr'
> Warning(drivers/net/phy/phy.c:313): Excess function parameter 'mii_data' description in 'phy_mii_ioctl'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] net/sock.h: add missing kernel-doc notation
From: David Miller @ 2010-08-10 7:09 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev
In-Reply-To: <20100809164107.a992561a.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 9 Aug 2010 16:41:07 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Add missing kernel-doc notation to struct sock:
>
> Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_pid'
> Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_cred'
> Warning(include/net/sock.h:324): No description found for parameter 'sk_classid'
> Warning(include/net/sock.h:324): Excess struct/union/enum/typedef member 'sk_peercred' description in 'sock'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] etherdevice.h: fix kernel-doc typo
From: David Miller @ 2010-08-10 7:09 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev
In-Reply-To: <20100809164003.39c496ee.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 9 Aug 2010 16:40:03 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix etherdevice.h parameter name typo in kernel-doc:
>
> Warning(include/linux/etherdevice.h:138): No description found for parameter 'hwaddr'
> Warning(include/linux/etherdevice.h:138): Excess function parameter 'addr' description in 'dev_hw_addr_random'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied.
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: David Miller @ 2010-08-10 7:07 UTC (permalink / raw)
To: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
Cc: greg-U8xfFu+wG4EAvxtiuMwx3w, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
vapier-aBrp7R+bbdUdnm+yROfE0A, jbarnes-Y1mF5jBUw70BENJcbMCuUQ,
kevin.curtis-AP8L3A0T/wQqdlJmJB21zg,
phillip-cnXvMjJKhjYG2Il/BtU0GPXRex20P6io,
faisal.latif-ral2JQCrhuEAvxtiuMwx3w,
chien.tin.tung-ral2JQCrhuEAvxtiuMwx3w,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
samuel.ortiz-ral2JQCrhuEAvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100809164346.6e30cf8c.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date: Mon, 9 Aug 2010 16:43:46 -0700
> drivers/net/wan/farsync.c: In function 'fst_intr_rx':
> drivers/net/wan/farsync.c:1312: warning: cast to pointer from integer of different size
> drivers/net/wan/farsync.c: In function 'do_bottom_half_tx':
> drivers/net/wan/farsync.c:1407: warning: cast to pointer from integer of different size
I'll toss the following into net-2.6:
--------------------
farsync: Fix compile warnings.
drivers/net/wan/farsync.c: In function 'fst_intr_rx':
drivers/net/wan/farsync.c:1312: warning: cast to pointer from integer of different size
drivers/net/wan/farsync.c: In function 'do_bottom_half_tx':
drivers/net/wan/farsync.c:1407: warning: cast to pointer from integer of different size
The "skb" and "mem" arguments being passed here are DMA addresses
being programmed into the hardware registers, so pass them as the type
that they actually are. And use the correct printf formatting in
debug logging statements for these things to match the type change.
Reported-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
---
drivers/net/wan/farsync.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index ad7719f..e050bd6 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -885,20 +885,21 @@ fst_rx_dma_complete(struct fst_card_info *card, struct fst_port_info *port,
* Receive a frame through the DMA
*/
static inline void
-fst_rx_dma(struct fst_card_info *card, unsigned char *skb,
- unsigned char *mem, int len)
+fst_rx_dma(struct fst_card_info *card, dma_addr_t skb,
+ dma_addr_t mem, int len)
{
/*
* This routine will setup the DMA and start it
*/
- dbg(DBG_RX, "In fst_rx_dma %p %p %d\n", skb, mem, len);
+ dbg(DBG_RX, "In fst_rx_dma %lx %lx %d\n",
+ (unsigned long) skb, (unsigned long) mem, len);
if (card->dmarx_in_progress) {
dbg(DBG_ASS, "In fst_rx_dma while dma in progress\n");
}
- outl((unsigned long) skb, card->pci_conf + DMAPADR0); /* Copy to here */
- outl((unsigned long) mem, card->pci_conf + DMALADR0); /* from here */
+ outl(skb, card->pci_conf + DMAPADR0); /* Copy to here */
+ outl(mem, card->pci_conf + DMALADR0); /* from here */
outl(len, card->pci_conf + DMASIZ0); /* for this length */
outl(0x00000000c, card->pci_conf + DMADPR0); /* In this direction */
@@ -1309,8 +1310,8 @@ fst_intr_rx(struct fst_card_info *card, struct fst_port_info *port)
card->dma_port_rx = port;
card->dma_len_rx = len;
card->dma_rxpos = rxp;
- fst_rx_dma(card, (char *) card->rx_dma_handle_card,
- (char *) BUF_OFFSET(rxBuffer[pi][rxp][0]), len);
+ fst_rx_dma(card, card->rx_dma_handle_card,
+ BUF_OFFSET(rxBuffer[pi][rxp][0]), len);
}
if (rxp != port->rxpos) {
dbg(DBG_ASS, "About to increment rxpos by more than 1\n");
--
1.7.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [patch 2/2] qlcnic: using too much stack
From: David Miller @ 2010-08-10 7:01 UTC (permalink / raw)
To: joe
Cc: anirban.chakraborty, error27, amit.salecha, Linux-Driver,
sucheta.chakraborty, netdev, kernel-janitors
In-Reply-To: <1281411546.1954.102.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Mon, 09 Aug 2010 20:39:06 -0700
> On Mon, 2010-08-09 at 20:31 -0700, Anirban Chakraborty wrote:
>> On Aug 10, 2010, at 7:33 AM, Joe Perches wrote:
>> > On Mon, 2010-08-09 at 18:43 -0700, Anirban Chakraborty wrote:
>> >> Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
>> >> argument that you are passing to kcalloc.
>> > You probably meant to write "my preferred way"
>> > as the kcalloc to "kzalloc with a multiply"
>> > ratio is pretty high.
>> I was suggesting based on the following:
>> http://lwn.net/Articles/147014/
>
> Note that article suggests kzalloc for allocating
> a single zeroed object.
>
> kcalloc is used for multiple zeroed objects and
> protects against oversized allocations.
Agreed, kcalloc should be used here.
^ permalink raw reply
* [patch] Staging: vt6656: problems in error handling
From: Dan Carpenter @ 2010-08-10 6:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andres More, Forest Bond, Jim Lieb, devel, netdev,
kernel-janitors
The first kfree(pDevice) is pointless because pDevice is NULL. The
second kfree(pDevice) is a double free because pDevice is the driver's
private data and that is already freed by free_netdev(netdev). Also the
free_netdev() error path doesn't call usb_put_dev().
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
index c528ef0..4fdf837 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -771,10 +771,9 @@ vt6656_probe(struct usb_interface *intf, const struct usb_device_id *id)
udev = usb_get_dev(udev);
netdev = alloc_etherdev(sizeof(DEVICE_INFO));
-
if (!netdev) {
printk(KERN_ERR DEVICE_NAME ": allocate net device failed\n");
- kfree(pDevice);
+ rc = -ENOMEM;
goto err_nomem;
}
@@ -800,9 +799,7 @@ vt6656_probe(struct usb_interface *intf, const struct usb_device_id *id)
rc = register_netdev(netdev);
if (rc) {
printk(KERN_ERR DEVICE_NAME " Failed to register netdev\n");
- free_netdev(netdev);
- kfree(pDevice);
- return -ENODEV;
+ goto err_netdev;
}
usb_device_reset(pDevice);
@@ -820,10 +817,12 @@ vt6656_probe(struct usb_interface *intf, const struct usb_device_id *id)
return 0;
+err_netdev:
+ free_netdev(netdev);
err_nomem:
usb_put_dev(udev);
- return -ENOMEM;
+ return rc;
}
static void device_free_tx_bufs(PSDevice pDevice)
^ permalink raw reply related
* Re: i386 allmodconfig, current mainline
From: Roland Dreier @ 2010-08-10 4:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis, Phillip Lougher, Faisal Latif, Chien Tung,
Dan Williams, Samuel Ortiz, linux-kernel, netdev, linux-wireless,
x86, linux-rdma
In-Reply-To: <20100809164346.6e30cf8c.akpm@linux-foundation.org>
Will queue up fixes as below:
> drivers/infiniband/hw/nes/nes_verbs.c: In function 'nes_alloc_fast_reg_page_list':
> drivers/infiniband/hw/nes/nes_verbs.c:477: warning: cast to pointer from integer of different size
> drivers/infiniband/hw/nes/nes_verbs.c: In function 'nes_post_send':
> drivers/infiniband/hw/nes/nes_verbs.c:3486: warning: cast to pointer from integer of different size
> drivers/infiniband/hw/nes/nes_verbs.c:3486: warning: cast to pointer from integer of different size
--- a/drivers/infiniband/hw/nes/nes_verbs.c
+++ b/drivers/infiniband/hw/nes/nes_verbs.c
@@ -476,9 +476,9 @@ static struct ib_fast_reg_page_list *nes_alloc_fast_reg_page_list(
}
nes_debug(NES_DBG_MR, "nes_alloc_fast_reg_pbl: nes_frpl = %p, "
"ibfrpl = %p, ibfrpl.page_list = %p, pbl.kva = %p, "
- "pbl.paddr= %p\n", pnesfrpl, &pnesfrpl->ibfrpl,
+ "pbl.paddr = %llx\n", pnesfrpl, &pnesfrpl->ibfrpl,
pnesfrpl->ibfrpl.page_list, pnesfrpl->nes_wqe_pbl.kva,
- (void *)pnesfrpl->nes_wqe_pbl.paddr);
+ (unsigned long long) pnesfrpl->nes_wqe_pbl.paddr);
return pifrpl;
}
@@ -3483,13 +3483,13 @@ static int nes_post_send(struct ib_qp *ibqp, struct ib_send_wr *ib_wr,
for (i = 0; i < ib_wr->wr.fast_reg.page_list_len; i++)
dst_page_list[i] = cpu_to_le64(src_page_list[i]);
- nes_debug(NES_DBG_IW_TX, "SQ_FMR: iova_start: %p, "
- "length: %d, rkey: %0x, pgl_paddr: %p, "
+ nes_debug(NES_DBG_IW_TX, "SQ_FMR: iova_start: %llx, "
+ "length: %d, rkey: %0x, pgl_paddr: %llx, "
"page_list_len: %u, wqe_misc: %x\n",
- (void *)ib_wr->wr.fast_reg.iova_start,
+ (unsigned long long) ib_wr->wr.fast_reg.iova_start,
ib_wr->wr.fast_reg.length,
ib_wr->wr.fast_reg.rkey,
- (void *)pnesfrpl->nes_wqe_pbl.paddr,
+ (unsigned long long) pnesfrpl->nes_wqe_pbl.paddr,
ib_wr->wr.fast_reg.page_list_len,
wqe_misc);
break;
> drivers/infiniband/hw/cxgb4/cq.c: In function 'destroy_cq':
> drivers/infiniband/hw/cxgb4/cq.c:58: warning: cast from pointer to integer of different size
> drivers/infiniband/hw/cxgb4/cq.c: In function 'create_cq':
> drivers/infiniband/hw/cxgb4/cq.c:135: warning: cast from pointer to integer of different size
There were a few more here, will queue:
--- a/drivers/infiniband/hw/cxgb4/cm.c
+++ b/drivers/infiniband/hw/cxgb4/cm.c
@@ -2323,7 +2323,7 @@ static int fw6_msg(struct c4iw_dev *dev, struct sk_buff *skb)
switch (rpl->type) {
case 1:
ret = (int)((be64_to_cpu(rpl->data[0]) >> 8) & 0xff);
- wr_waitp = (__force struct c4iw_wr_wait *)rpl->data[1];
+ wr_waitp = (struct c4iw_wr_wait *)(__force unsigned long) rpl->data[1];
PDBG("%s wr_waitp %p ret %u\n", __func__, wr_waitp, ret);
if (wr_waitp) {
wr_waitp->ret = ret;
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b/drivers/infiniband/hw/cxgb4/cq.c
index b3daf39..af684fc 100644
--- a/drivers/infiniband/hw/cxgb4/cq.c
+++ b/drivers/infiniband/hw/cxgb4/cq.c
@@ -55,7 +55,7 @@ static int destroy_cq(struct c4iw_rdev *rdev, struct t4_cq *cq,
V_FW_RI_RES_WR_NRES(1) |
FW_WR_COMPL(1));
res_wr->len16_pkd = cpu_to_be32(DIV_ROUND_UP(wr_len, 16));
- res_wr->cookie = (u64)&wr_wait;
+ res_wr->cookie = (unsigned long) &wr_wait;
res = res_wr->res;
res->u.cq.restype = FW_RI_RES_TYPE_CQ;
res->u.cq.op = FW_RI_RES_OP_RESET;
@@ -132,7 +132,7 @@ static int create_cq(struct c4iw_rdev *rdev, struct t4_cq *cq,
V_FW_RI_RES_WR_NRES(1) |
FW_WR_COMPL(1));
res_wr->len16_pkd = cpu_to_be32(DIV_ROUND_UP(wr_len, 16));
- res_wr->cookie = (u64)&wr_wait;
+ res_wr->cookie = (unsigned long) &wr_wait;
res = res_wr->res;
res->u.cq.restype = FW_RI_RES_TYPE_CQ;
res->u.cq.op = FW_RI_RES_OP_WRITE;
--- a/drivers/infiniband/hw/cxgb4/mem.c
+++ b/drivers/infiniband/hw/cxgb4/mem.c
@@ -71,7 +71,7 @@ static int write_adapter_mem(struct c4iw_rdev *rdev, u32 addr, u32 len,
if (i == (num_wqe-1)) {
req->wr.wr_hi = cpu_to_be32(FW_WR_OP(FW_ULPTX_WR) |
FW_WR_COMPL(1));
- req->wr.wr_lo = (__force __be64)&wr_wait;
+ req->wr.wr_lo = (__force __be64)(unsigned long) &wr_wait;
} else
req->wr.wr_hi = cpu_to_be32(FW_WR_OP(FW_ULPTX_WR));
req->wr.wr_mid = cpu_to_be32(
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -144,7 +144,7 @@ static int create_qp(struct c4iw_rdev *rdev, struct t4_wq *wq,
V_FW_RI_RES_WR_NRES(2) |
FW_WR_COMPL(1));
res_wr->len16_pkd = cpu_to_be32(DIV_ROUND_UP(wr_len, 16));
- res_wr->cookie = (u64)&wr_wait;
+ res_wr->cookie = (unsigned long) &wr_wait;
res = res_wr->res;
res->u.sqrq.restype = FW_RI_RES_TYPE_SQ;
res->u.sqrq.op = FW_RI_RES_OP_WRITE;
@@ -985,7 +985,7 @@ static int rdma_fini(struct c4iw_dev *rhp, struct c4iw_qp *qhp,
wqe->flowid_len16 = cpu_to_be32(
FW_WR_FLOWID(ep->hwtid) |
FW_WR_LEN16(DIV_ROUND_UP(sizeof *wqe, 16)));
- wqe->cookie = (u64)&wr_wait;
+ wqe->cookie = (unsigned long) &wr_wait;
wqe->u.fini.type = FW_RI_TYPE_FINI;
c4iw_init_wr_wait(&wr_wait);
@@ -1060,7 +1060,7 @@ static int rdma_init(struct c4iw_dev *rhp, struct c4iw_qp *qhp)
FW_WR_FLOWID(qhp->ep->hwtid) |
FW_WR_LEN16(DIV_ROUND_UP(sizeof *wqe, 16)));
- wqe->cookie = (u64)&wr_wait;
+ wqe->cookie = (unsigned long) &wr_wait;
wqe->u.init.type = FW_RI_TYPE_INIT;
wqe->u.init.mpareqbit_p2ptype =
--
Roland Dreier <rolandd@cisco.com> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
^ permalink raw reply related
* Re: [PATCH net-next-2.6] bridge: 64bit rx/tx counters
From: Andrew Morton @ 2010-08-10 4:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Stephen Hemminger, netdev, bhutchings, Nick Piggin
In-Reply-To: <1276598376.2541.93.camel@edumazet-laptop>
On Tue, 15 Jun 2010 12:39:36 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Note : should be applied after "net: Introduce
> u64_stats_sync infrastructure", if accepted.
>
>
> Thanks
>
> [PATCH net-next-2.6] bridge: 64bit rx/tx counters
>
> Use u64_stats_sync infrastructure to provide 64bit rx/tx
> counters even on 32bit hosts.
>
> It is safe to use a single u64_stats_sync for rx and tx,
> because BH is disabled on both, and we use per_cpu data.
>
Oh for fuck's sake. Will you guys just stop adding generic kernel
infrastructure behind everyone's backs?
Had I actually been aware that this stuff was going into the tree I'd
have pointed out that the u64_stats_* api needs renaming.
s/stats/counter/ because it has no business assuming that the counter
is being used for statistics.
And all this open-coded per-cpu counter stuff added all over the place.
Were percpu_counters tested or reviewed and found inadequate and unfixable?
If so, please do tell.
^ permalink raw reply
* Re: Auto generation of IPv6 link local address
From: Michał Mirosław @ 2010-08-10 4:32 UTC (permalink / raw)
To: Jon Smirl; +Cc: Netdev
In-Reply-To: <AANLkTik80QZ=KdHGuT99ftx19RcHq2KOUPMR-Lhho5aL@mail.gmail.com>
2010/8/10 Jon Smirl <jonsmirl@gmail.com>:
> When I bring my Ethernet interface up it automatically gets a link
> local IPv6 address.
>
> eth3 Link encap:Ethernet HWaddr 00:1b:21:59:65:32
> inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0
> inet6 addr: fe80::21b:21ff:fe59:6532/64 Scope:Link -->
> Missing from my driver
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:1836635 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1283010 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:2259859914 (2.2 GB) TX bytes:121836850 (121.8 MB)
> Interrupt:16 Memory:dbd60000-dbd80000
>
> I'm writing a device driver for new 802.15.4 hardware. When I bring it
> up I don't get an automatic IPv6 link local address. What controls
> whether an adapter gets a link local address added or not? My driver
> should get one so I must have something wrong in my code.
>
> wpan0 Link encap:IEEE 802.15.4 HWaddr 00:50:c2:ff:fe:a8:a8:c5
> UP BROADCAST RUNNING NOARP MTU:1280 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:10
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
addrconf_notify() in linux-2.6.34/net/ipv6/addrconf.c does not have
code for IEEE 802.15.4. I don't know much about 802.15.4, but if IPv6
with static addresses works over it, then adding support for
autogenerated addresses should be easy (just addrconf_dev_config() and
ipv6_generate_eui64()?).
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [patch 2/2] qlcnic: using too much stack
From: Joe Perches @ 2010-08-10 3:39 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: Dan Carpenter, Amit Salecha, Linux Driver, David S. Miller,
Sucheta Chakraborty, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <D084A42E-7F2A-44F7-9273-DDD9214CB877@qlogic.com>
On Mon, 2010-08-09 at 20:31 -0700, Anirban Chakraborty wrote:
> On Aug 10, 2010, at 7:33 AM, Joe Perches wrote:
> > On Mon, 2010-08-09 at 18:43 -0700, Anirban Chakraborty wrote:
> >> Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
> >> argument that you are passing to kcalloc.
> > You probably meant to write "my preferred way"
> > as the kcalloc to "kzalloc with a multiply"
> > ratio is pretty high.
> I was suggesting based on the following:
> http://lwn.net/Articles/147014/
Note that article suggests kzalloc for allocating
a single zeroed object.
kcalloc is used for multiple zeroed objects and
protects against oversized allocations.
^ permalink raw reply
* Re: [patch 2/2] qlcnic: using too much stack
From: Anirban Chakraborty @ 2010-08-10 3:31 UTC (permalink / raw)
To: Joe Perches
Cc: Dan Carpenter, Amit Salecha, Linux Driver, David S. Miller,
Sucheta Chakraborty, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <1281405801.1954.65.camel@Joe-Laptop.home>
On Aug 10, 2010, at 7:33 AM, Joe Perches wrote:
> On Mon, 2010-08-09 at 18:43 -0700, Anirban Chakraborty wrote:
>> Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
>> argument that you are passing to kcalloc.
>
> You probably meant to write "my preferred way"
> as the kcalloc to "kzalloc with a multiply"
> ratio is pretty high.
>
> It's actually about 2.5 to 1 in favor of kcalloc.
>
> $ grep -rw --include=*.[ch] kcalloc * | wc -l
> 419
>
> $ grep -rP --include=*.[ch] "\bkzalloc\s*\(\s*\w+\s*\*\s*\w+" * | \
> grep -vP "\bkzalloc\s*\(\s*sizeof\s+\*\s*\w+\s*," | wc -l
> 164
>
> (the grep -vP avoids kzalloc(sizeof *p, GFP_foo)
>
> Actually, there might be a reason to use kzalloc
> in that location to match the other similar use
> a few lines away, but I'd prefer that the other
> use be converted to kcalloc.
I was suggesting based on the following:
http://lwn.net/Articles/147014/
thanks,
Anirban
^ permalink raw reply
* Auto generation of IPv6 link local address
From: Jon Smirl @ 2010-08-10 3:04 UTC (permalink / raw)
To: Netdev
When I bring my Ethernet interface up it automatically gets a link
local IPv6 address.
eth3 Link encap:Ethernet HWaddr 00:1b:21:59:65:32
inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21b:21ff:fe59:6532/64 Scope:Link -->
Missing from my driver
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1836635 errors:0 dropped:0 overruns:0 frame:0
TX packets:1283010 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2259859914 (2.2 GB) TX bytes:121836850 (121.8 MB)
Interrupt:16 Memory:dbd60000-dbd80000
I'm writing a device driver for new 802.15.4 hardware. When I bring it
up I don't get an automatic IPv6 link local address. What controls
whether an adapter gets a link local address added or not? My driver
should get one so I must have something wrong in my code.
wpan0 Link encap:IEEE 802.15.4 HWaddr 00:50:c2:ff:fe:a8:a8:c5
UP BROADCAST RUNNING NOARP MTU:1280 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [patch 2/2] qlcnic: using too much stack
From: Joe Perches @ 2010-08-10 2:03 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: Dan Carpenter, Amit Salecha, Linux Driver, David S. Miller,
Sucheta Chakraborty, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <9F31A875-3A0B-4518-8106-1012E0D2799B@qlogic.com>
On Mon, 2010-08-09 at 18:43 -0700, Anirban Chakraborty wrote:
> Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
> argument that you are passing to kcalloc.
You probably meant to write "my preferred way"
as the kcalloc to "kzalloc with a multiply"
ratio is pretty high.
It's actually about 2.5 to 1 in favor of kcalloc.
$ grep -rw --include=*.[ch] kcalloc * | wc -l
419
$ grep -rP --include=*.[ch] "\bkzalloc\s*\(\s*\w+\s*\*\s*\w+" * | \
grep -vP "\bkzalloc\s*\(\s*sizeof\s+\*\s*\w+\s*," | wc -l
164
(the grep -vP avoids kzalloc(sizeof *p, GFP_foo)
Actually, there might be a reason to use kzalloc
in that location to match the other similar use
a few lines away, but I'd prefer that the other
use be converted to kcalloc.
cheers, Joe
^ permalink raw reply
* Re: [patch 2/2] qlcnic: using too much stack
From: Anirban Chakraborty @ 2010-08-10 1:43 UTC (permalink / raw)
To: Dan Carpenter
Cc: Amit Salecha, Linux Driver, David S. Miller, Sucheta Chakraborty,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20100809184254.GJ9031@bicker>
On Aug 10, 2010, at 12:12 AM, Dan Carpenter wrote:
> On Mon, Aug 09, 2010 at 09:46:32AM -0700, Anirban Chakraborty wrote:
>>
>> It looks fine except that I'd use kzalloc instead of kcalloc above.
>>
>
> It's no problem to do that, and I'm already respinning the patches but
> I'm confused. It looks like pci_info gets initialized correctly. What
> am I missing?
Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
argument that you are passing to kcalloc.
-Anirban
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: Dan Williams @ 2010-08-10 0:42 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis, Phillip Lougher, Latif, Faisal, Tung, Chien Tin,
Ortiz, Samuel,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20100809164346.6e30cf8c.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On 8/9/2010 4:43 PM, Andrew Morton wrote:
>
> Guys. What's goin' on out there?
[..]
>
> drivers/dma/timb_dma.c: In function 'td_fill_desc':
> drivers/dma/timb_dma.c:203: warning: cast to pointer from integer of different size
The fix for this one is pending in my 2.6.36 pull request. I added the
missing ARCH=i386, CONFIG_HIGHMEM64G=y case to my build regression script.
--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: David Woodhouse @ 2010-08-10 0:32 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, Mike Frysinger, Jesse Barnes, Kevin Curtis,
Phillip Lougher, Faisal Latif, Chien Tung, Dan Williams,
Samuel Ortiz, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100809164346.6e30cf8c.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Mon, 2010-08-09 at 16:43 -0700, Andrew Morton wrote:
>
> drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in initializer
> drivers/power/olpc_battery.c:387: warning: initialization from incompatible pointer type
> make[2]: *** [drivers/power/olpc_battery.o] Error 1
> make[1]: *** [drivers/power] Error 2
I fixed that today.
> drivers/mtd/maps/gpio-addr-flash.c: In function 'gpio_flash_probe':
> drivers/mtd/maps/gpio-addr-flash.c:212: warning: cast to pointer from integer of different size
> drivers/mtd/maps/gpio-addr-flash.c:224: warning: cast to pointer from integer of different size
Ew. Mike? Is this a nommu driver which is missing an ioremap()?
> drivers/pci/intel-iommu.c: In function 'dma_pte_addr':
> drivers/pci/intel-iommu.c:239: warning: passing argument 1 of '__cmpxchg64' from incompatible pointer type
- return __cmpxchg64(pte, 0ULL, 0ULL) & VTD_PAGE_MASK;
+ return __cmpxchg64(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
Will test and push.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: Stephen Rothwell @ 2010-08-10 0:15 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis, Phillip Lougher, Faisal Latif, Chien Tung,
Dan Williams, Samuel Ortiz, linux-kernel, netdev, linux-wireless,
x86, linux-rdma
In-Reply-To: <20100809164346.6e30cf8c.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
Hi Andrew,
On Mon, 9 Aug 2010 16:43:46 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Guys. What's goin' on out there?
I guess we are all so up to date that noone does 32 bit builds any
more ... Also noone is bothering to look at the build logs:
linus tree: http://kisskb.ellerman.id.au/kisskb/branch/3/
linux-next: http://kisskb.ellerman.id.au/kisskb/branch/9/
> drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in initializer
This is known and should be fixed in today's -next and hopefully being
sent to Linus.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: Randy Dunlap @ 2010-08-09 23:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis, Phillip Lougher, Faisal Latif, Chien Tung,
Dan Williams, Samuel Ortiz, linux-kernel, netdev, linux-wireless,
x86, linux-rdma
In-Reply-To: <20100809164346.6e30cf8c.akpm@linux-foundation.org>
On Mon, 9 Aug 2010 16:43:46 -0700 Andrew Morton wrote:
>
> Guys. What's goin' on out there?
>
>
> drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in initializer
> drivers/power/olpc_battery.c:387: warning: initialization from incompatible pointer type
> make[2]: *** [drivers/power/olpc_battery.o] Error 1
> make[1]: *** [drivers/power] Error 2
David Woodhouse fixed this one today.
> fs/squashfs/xattr.c:37: warning: 'squashfs_xattr_handler' declared inline after being called
> fs/squashfs/xattr.c:37: warning: previous declaration of 'squashfs_xattr_handler' was here
I see this one on one system (with gcc 4.1.2) but not on f11 with gcc 4.4.1,
although it should be OK to "fix" it.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* [PATCH 2/3] net/sock.h: add missing kernel-doc notation
From: Randy Dunlap @ 2010-08-09 23:41 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <randy.dunlap@oracle.com>
Add missing kernel-doc notation to struct sock:
Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_pid'
Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_cred'
Warning(include/net/sock.h:324): No description found for parameter 'sk_classid'
Warning(include/net/sock.h:324): Excess struct/union/enum/typedef member 'sk_peercred' description in 'sock'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
include/net/sock.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.35-git8.orig/include/net/sock.h
+++ linux-2.6.35-git8/include/net/sock.h
@@ -195,7 +195,8 @@ struct sock_common {
* @sk_priority: %SO_PRIORITY setting
* @sk_type: socket type (%SOCK_STREAM, etc)
* @sk_protocol: which protocol this socket belongs in this network family
- * @sk_peercred: %SO_PEERCRED setting
+ * @sk_peer_pid: &struct pid for this socket's peer
+ * @sk_peer_cred: %SO_PEERCRED setting
* @sk_rcvlowat: %SO_RCVLOWAT setting
* @sk_rcvtimeo: %SO_RCVTIMEO setting
* @sk_sndtimeo: %SO_SNDTIMEO setting
@@ -211,6 +212,7 @@ struct sock_common {
* @sk_send_head: front of stuff to transmit
* @sk_security: used by security modules
* @sk_mark: generic packet mark
+ * @sk_classid: this socket's cgroup classid
* @sk_write_pending: a write to stream socket waits to start
* @sk_state_change: callback to indicate change in the state of the sock
* @sk_data_ready: callback to indicate there is data to be processed
^ permalink raw reply
* i386 allmodconfig, current mainline
From: Andrew Morton @ 2010-08-09 23:43 UTC (permalink / raw)
To: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis
Cc: linux-kernel, netdev, linux-wireless, x86, linux-rdma
Guys. What's goin' on out there?
drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in initializer
drivers/power/olpc_battery.c:387: warning: initialization from incompatible pointer type
make[2]: *** [drivers/power/olpc_battery.o] Error 1
make[1]: *** [drivers/power] Error 2
drivers/mtd/maps/gpio-addr-flash.c: In function 'gpio_flash_probe':
drivers/mtd/maps/gpio-addr-flash.c:212: warning: cast to pointer from integer of different size
drivers/mtd/maps/gpio-addr-flash.c:224: warning: cast to pointer from integer of different size
drivers/pci/intel-iommu.c: In function 'dma_pte_addr':
drivers/pci/intel-iommu.c:239: warning: passing argument 1 of '__cmpxchg64' from incompatible pointer type
drivers/net/wan/farsync.c: In function 'fst_intr_rx':
drivers/net/wan/farsync.c:1312: warning: cast to pointer from integer of different size
drivers/net/wan/farsync.c: In function 'do_bottom_half_tx':
drivers/net/wan/farsync.c:1407: warning: cast to pointer from integer of different size
fs/squashfs/xattr.c:37: warning: 'squashfs_xattr_handler' declared inline after being called
fs/squashfs/xattr.c:37: warning: previous declaration of 'squashfs_xattr_handler' was here
drivers/net/wireless/ipw2x00/ipw2100.c: In function 'ipw2100_tx_send_commands':
drivers/net/wireless/ipw2x00/ipw2100.c:3063: warning: cast to pointer from integer of different size
In file included from drivers/platform/x86/intel_scu_ipc.c:26:
/usr/src/devel/arch/x86/include/asm/mrst.h:14: warning: 'struct sfi_table_header' declared inside parameter list
/usr/src/devel/arch/x86/include/asm/mrst.h:14: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/infiniband/hw/nes/nes_verbs.c: In function 'nes_alloc_fast_reg_page_list':
drivers/infiniband/hw/nes/nes_verbs.c:477: warning: cast to pointer from integer of different size
drivers/infiniband/hw/nes/nes_verbs.c: In function 'nes_post_send':
drivers/infiniband/hw/nes/nes_verbs.c:3486: warning: cast to pointer from integer of different size
drivers/infiniband/hw/nes/nes_verbs.c:3486: warning: cast to pointer from integer of different size
drivers/infiniband/hw/cxgb4/cq.c: In function 'destroy_cq':
drivers/infiniband/hw/cxgb4/cq.c:58: warning: cast from pointer to integer of different size
drivers/infiniband/hw/cxgb4/cq.c: In function 'create_cq':
drivers/infiniband/hw/cxgb4/cq.c:135: warning: cast from pointer to integer of different size
drivers/dma/timb_dma.c: In function 'td_fill_desc':
drivers/dma/timb_dma.c:203: warning: cast to pointer from integer of different size
drivers/net/wireless/iwmc3200wifi/rx.c: In function 'iwm_ntf_wifi_if_wrapper':
drivers/net/wireless/iwmc3200wifi/rx.c:1198: warning: comparison is always true due to limited range of data type
^ permalink raw reply
* [PATCH 1/3] etherdevice.h: fix kernel-doc typo
From: Randy Dunlap @ 2010-08-09 23:40 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix etherdevice.h parameter name typo in kernel-doc:
Warning(include/linux/etherdevice.h:138): No description found for parameter 'hwaddr'
Warning(include/linux/etherdevice.h:138): Excess function parameter 'addr' description in 'dev_hw_addr_random'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
include/linux/etherdevice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.35-git8.orig/include/linux/etherdevice.h
+++ linux-2.6.35-git8/include/linux/etherdevice.h
@@ -129,7 +129,7 @@ static inline void random_ether_addr(u8
/**
* dev_hw_addr_random - Create random MAC and set device flag
* @dev: pointer to net_device structure
- * @addr: Pointer to a six-byte array containing the Ethernet address
+ * @hwaddr: Pointer to a six-byte array containing the Ethernet address
*
* Generate random MAC to be used by a device and set addr_assign_type
* so the state can be read by sysfs and be used by udev.
^ 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