Since every caller has to squirrel away the returned pointer anyway, they might as well supply the memory area. This fixes a bug in a few of the call sites where the returned pointer was dereferenced without checking it for NULL (which gets returned if the kzalloc failed). I'd like to hear how sound and netdev feels about this: it will add about two more pointers worth of data to struct netdev and struct snd_pcm_substream .. but I think it's worth it. If you're OK, I'll add your acks and send through the pm tree. This also looks to me like an android independent clean up (even though it renders the request_add atomically callable). I also added include guards to include/linux/pm_qos_params.h cc: netdev@vger.kernel.org cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: James Bottomley <James.Bottomley@suse.de> --- drivers/net/e1000e/netdev.c | 17 +++----- drivers/net/igbvf/netdev.c | 9 ++-- drivers/net/wireless/ipw2x00/ipw2100.c | 12 +++--- include/linux/netdevice.h | 2 +- include/linux/pm_qos_params.h | 13 +++++- include/sound/pcm.h | 2 +- kernel/pm_qos_params.c | 67 +++++++++++++++++++------------- sound/core/pcm_native.c | 13 ++---- 8 files changed, 74 insertions(+), 61 deletions(-) diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c index 24507f3..47ea62f 100644 --- a/drivers/net/e1000e/netdev.c +++ b/drivers/net/e1000e/netdev.c @@ -2901,10 +2901,10 @@ static void e1000_configure_rx(struct e1000_adapter *adapter) * dropped transactions. */ pm_qos_update_request( - adapter->netdev->pm_qos_req, 55); + &adapter->netdev->pm_qos_req, 55); } else { pm_qos_update_request( - adapter->netdev->pm_qos_req, + &adapter->netdev->pm_qos_req, PM_QOS_DEFAULT_VALUE); } } @@ -3196,9 +3196,9 @@ int e1000e_up(struct e1000_adapter *adapter) /* DMA latency requirement to workaround ...
I like all of the patches in this series, thanks a lot for doing this! I guess it might be worth sending a CC to the LKML next round so that people can see [1/3] (I don't expect any objections, but anyway it would be nice). Thanks, Rafael --
I cc'd the latest owners of plist.h ... although Daniel Walker has apparently since left MontaVista, Thomas Gleixner is still current ... and he can speak for the RT people, who are the primary plist users. I can do another round and cc lkml, I was just hoping this would be the last revision. James --
OK, let's see if there's any feedback on [3/3] from netdev and Takashi. If there's none, I'll just put the series into my linux-next branch. Rafael --
I'm still paying attention tho .. I didn't see anything objection worthy in the plist changes.. If you do send another round you might want to add Oleg Nesterov , most of the code was redone by him .. Daniel --
Thank you for doing this!, I'll integrate it into some testing targets in the morning! Signed-off-by: mark gross <markgross@thegnar.org> --
I would apply this one too, but I need a final changelog for it. Care to send? Rafael --
How about: All current users of pm_qos_add_request() have the ability to supply the memory required by the pm_qos routines, so make them do this and eliminate the kmalloc() with pm_qos_add_request(). This has the double benefit of making the call never fail and allowing it to be called from atomic context. + signoffs James --
Hi, sorry for the late reply, as I've been on vacation in the last week (and shut off mails intentionally :) At Mon, 28 Jun 2010 12:44:48 -0500, I like the patch very well, too. Is this correct...? Shouldn't it be a negative check? thanks, Takashi --
Yes, it should be a negative check ... I'll update the patch. I guess this still means that no-one has managed to test it on a functional system ... James --
well I guess that explains the warning I got on my back port of this patch. [ 62.944788] ------------[ cut here ]------------ [ 62.944788] WARNING: at kernel/pm_qos_params.c:266 pm_qos_update_request+0x21/0x46) [ 62.944788] pm_qos_update_request() called for unknown object [ 62.944788] Modules linked in: mrst_sspi cfspi_slave chnl_chr caif_chr chnl_net caf [ 62.944788] Pid: 91, comm: mrst/0 Tainted: G W 2.6.31.6-mrst #30 [ 62.944788] Call Trace: [ 62.944788] [<c0145b2e>] ? pm_qos_update_request+0x21/0x46 [ 62.944788] [<c012fff3>] warn_slowpath_common+0x60/0x77 [ 62.944788] [<c013003e>] warn_slowpath_fmt+0x24/0x27 [ 62.944788] [<c0145b2e>] pm_qos_update_request+0x21/0x46 [ 62.944788] [<c03029f2>] int_transfer_complete_work+0x19/0x65 [ 62.944788] [<c013f02a>] worker_thread+0x153/0x1df [ 62.944788] [<c03029d9>] ? int_transfer_complete_work+0x0/0x65 [ 62.944788] [<c0141df1>] ? autoremove_wake_function+0x0/0x30 [ 62.944788] [<c0141c7c>] kthread+0x64/0x69 [ 62.944788] [<c013eed7>] ? worker_thread+0x0/0x1df [ 62.944788] [<c0141c18>] ? kthread+0x0/0x69 [ 62.944788] [<c01034df>] kernel_thread_helper+0x7/0x10 [ 62.944788] ---[ end trace 1723851b79e06c5d ]--- [ ...
Well, it's been for a while in linux-next ... Rafael --
Ah, OK, thanks ... so that would explain why we haven't been getting So here's hoping ... James --
