aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/misc/ibmasm/ibmasmfs.c (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2010-08-04virtio_net: implements ethtool_ops.get_drvinfoRusty Russell1-0/+14
I often use "ethtool -i" command to check what driver controls the ehternet device. But because current virtio_net driver doesn't support "ethtool -i", it becomes the following: # ethtool -i eth3 Cannot get driver information: Operation not supported This patch simply adds the "ethtool -i" support. The following is the result when using the virtio_net driver with my patch applied to. # ethtool -i eth3 driver: virtio_net version: N/A firmware-version: N/A bus-info: virtio0 Personally, "-i" is one of the most frequently-used option, and most network drivers support "ethtool -i", so I think virtio_net also should do. Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (use ARRAY_SIZE) Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04ppp: make channel_ops conststephen hemminger8-13/+16
The PPP channel ops structure should be const. Cleanup the declarations to use standard C99 format. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04RxRPC: Fix a potential deadlock between the call resend_timer and state_lockDavid Howells2-4/+5
RxRPC can potentially deadlock as rxrpc_resend_time_expired() wants to get call->state_lock so that it can alter the state of an RxRPC call. However, its caller (call_timer_fn()) has an apparent lock on the timer struct. The problem is that rxrpc_resend_time_expired() isn't permitted to lock call->state_lock as this could cause a deadlock against rxrpc_send_abort() as that takes state_lock and then attempts to delete the resend timer by calling del_timer_sync(). The deadlock can occur because del_timer_sync() will sit there forever waiting for rxrpc_resend_time_expired() to return, but the latter may then wait for call->state_lock, which rxrpc_send_abort() holds around del_timer_sync()... This leads to a warning appearing in the kernel log that looks something like the attached. It should be sufficient to simply dispense with the locks. It doesn't matter if we set the resend timer expired event bit and queue the event processor whilst we're changing state to one where the resend timer is irrelevant as the event can just be ignored by the processor thereafter. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.35-rc3-cachefs+ #115 ------------------------------------------------------- swapper/0 is trying to acquire lock: (&call->state_lock){++--..}, at: [<ffffffffa00200d4>] rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] but task is already holding lock: (&call->resend_timer){+.-...}, at: [<ffffffff8103b675>] run_timer_softirq+0x182/0x2a5 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&call->resend_timer){+.-...}: [<ffffffff810560bc>] __lock_acquire+0x889/0x8fa [<ffffffff81056184>] lock_acquire+0x57/0x6d [<ffffffff8103bb9c>] del_timer_sync+0x3c/0x86 [<ffffffffa002bb7a>] rxrpc_send_abort+0x50/0x97 [af_rxrpc] [<ffffffffa002bdd9>] rxrpc_kernel_abort_call+0xa1/0xdd [af_rxrpc] [<ffffffffa0061588>] afs_deliver_to_call+0x129/0x368 [kafs] [<ffffffffa006181b>] afs_process_async_call+0x54/0xff [kafs] [<ffffffff8104261d>] worker_thread+0x1ef/0x2e2 [<ffffffff81045f47>] kthread+0x7a/0x82 [<ffffffff81002cd4>] kernel_thread_helper+0x4/0x10 -> #0 (&call->state_lock){++--..}: [<ffffffff81055237>] validate_chain+0x727/0xd23 [<ffffffff810560bc>] __lock_acquire+0x889/0x8fa [<ffffffff81056184>] lock_acquire+0x57/0x6d [<ffffffff813e6b69>] _raw_read_lock_bh+0x34/0x43 [<ffffffffa00200d4>] rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] [<ffffffff8103b6e6>] run_timer_softirq+0x1f3/0x2a5 [<ffffffff81036828>] __do_softirq+0xa2/0x13e [<ffffffff81002dcc>] call_softirq+0x1c/0x28 [<ffffffff810049f0>] do_softirq+0x38/0x80 [<ffffffff810361a2>] irq_exit+0x45/0x47 [<ffffffff81018fb3>] smp_apic_timer_interrupt+0x88/0x96 [<ffffffff81002893>] apic_timer_interrupt+0x13/0x20 [<ffffffff810011ac>] cpu_idle+0x4d/0x83 [<ffffffff813e06f3>] start_secondary+0x1bd/0x1c1 other info that might help us debug this: 1 lock held by swapper/0: #0: (&call->resend_timer){+.-...}, at: [<ffffffff8103b675>] run_timer_softirq+0x182/0x2a5 stack backtrace: Pid: 0, comm: swapper Not tainted 2.6.35-rc3-cachefs+ #115 Call Trace: <IRQ> [<ffffffff81054414>] print_circular_bug+0xae/0xbd [<ffffffff81055237>] validate_chain+0x727/0xd23 [<ffffffff810560bc>] __lock_acquire+0x889/0x8fa [<ffffffff810539a7>] ? mark_lock+0x42f/0x51f [<ffffffff81056184>] lock_acquire+0x57/0x6d [<ffffffffa00200d4>] ? rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] [<ffffffff813e6b69>] _raw_read_lock_bh+0x34/0x43 [<ffffffffa00200d4>] ? rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] [<ffffffffa00200d4>] rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] [<ffffffff8103b6e6>] run_timer_softirq+0x1f3/0x2a5 [<ffffffff8103b675>] ? run_timer_softirq+0x182/0x2a5 [<ffffffffa002007e>] ? rxrpc_resend_time_expired+0x0/0x96 [af_rxrpc] [<ffffffff810367ef>] ? __do_softirq+0x69/0x13e [<ffffffff81036828>] __do_softirq+0xa2/0x13e [<ffffffff81002dcc>] call_softirq+0x1c/0x28 [<ffffffff810049f0>] do_softirq+0x38/0x80 [<ffffffff810361a2>] irq_exit+0x45/0x47 [<ffffffff81018fb3>] smp_apic_timer_interrupt+0x88/0x96 [<ffffffff81002893>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff81049de1>] ? __atomic_notifier_call_chain+0x0/0x86 [<ffffffff8100955b>] ? mwait_idle+0x6e/0x78 [<ffffffff81009552>] ? mwait_idle+0x65/0x78 [<ffffffff810011ac>] cpu_idle+0x4d/0x83 [<ffffffff813e06f3>] start_secondary+0x1bd/0x1c1 Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04sch_sfq: add sanity check for the packet lengthChangli Gao1-9/+20
The packet length should be checked before the packet data is dereferenced. Signed-off-by: Changli Gao <xiaosuo@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04cls_rsvp: add sanity check for the packet lengthChangli Gao1-2/+10
The packet length should be checked before the packet data is dereferenced. Signed-off-by: Changli Gao <xiaosuo@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04cls_flow: add sanity check for the packet lengthChangli Gao1-40/+56
The packet length should be checked before the packet data is dereferenced. Signed-off-by: Changli Gao <xiaosuo@gmail.com> Acked-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04sk_buff: introduce pskb_network_may_pull()Changli Gao1-0/+5
Signed-off-by: Changli Gao <xiaosuo@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04act_nat: fix on the TX pathChangli Gao1-10/+13
On the TX path, skb->data points to the ethernet header, not the network header. So when validating the packet length for accessing we should take the ethernet header into account. Signed-off-by: Changli Gao <xiaosuo@gmail.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04drivers/net/enic: Use %pUB to format a UUIDJoe Perches1-15/+2
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04davinci_emac: Fix use after free in davinci_emac_removeStefan Weil1-1/+1
free_netdev finally calls kfree which makes the contents of ndev and priv (private data contained in ndev) invalid. So iounmap should be called before free_netdev. Cc: David S. Miller <davem@davemloft.net> Cc: Chaithrika U S <chaithrika@ti.com> Cc: Sriramakrishnan <srk@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Weil <weil@mail.berlios.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04via-velocity: do not use PCI resources before pci_enable_device()Kulikov Vasiliy1-2/+2
IRQ and resource[] may not have correct values until after PCI hotplug setup occurs at pci_enable_device() time. The semantic match that finds this problem is as follows: // <smpl> @@ identifier x; identifier request ~= "pci_request.*|pci_resource.*"; @@ ( * x->irq | * x->resource | * request(x, ...) ) ... *pci_enable_device(x) // </smpl> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04cxgb4vf: do not use PCI resources before pci_enable_device()Kulikov Vasiliy1-15/+16
IRQ and resource[] may not have correct values until after PCI hotplug setup occurs at pci_enable_device() time. The semantic match that finds this problem is as follows: // <smpl> @@ identifier x; identifier request ~= "pci_request.*|pci_resource.*"; @@ ( * x->irq | * x->resource | * request(x, ...) ) ... *pci_enable_device(x) // </smpl> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04cxgb3: do not use PCI resources before pci_enable_device()Kulikov Vasiliy1-12/+13
IRQ and resource[] may not have correct values until after PCI hotplug setup occurs at pci_enable_device() time. The semantic match that finds this problem is as follows: // <smpl> @@ identifier x; identifier request ~= "pci_request.*|pci_resource.*"; @@ ( * x->irq | * x->resource | * request(x, ...) ) ... *pci_enable_device(x) // </smpl> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-04CRED: Fix RCU warning due to previous patch fixing __task_cred()'s checksDavid Howells1-3/+6
Commit 8f92054e7ca1 ("CRED: Fix __task_cred()'s lockdep check and banner comment") fixed the lockdep checks on __task_cred(). This has shown up a place in the signalling code where a lock should be held - namely that check_kill_permission() requires its callers to hold the RCU lock. Fix group_send_sig_info() to get the RCU read lock around its call to check_kill_permission(). Without this patch, the following warning can occur: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/signal.c:660 invoked rcu_dereference_check() without protection! ... Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-04block_dev: always serialize exclusive open attemptsTejun Heo1-2/+2
bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug. https://bugzilla.kernel.org/show_bug.cgi?id=16393 __bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block. This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk. stable: only applicable to v2.6.35 Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-04parisc: pass through '\t' to early (iodc) consoleKyle McMartin1-10/+2
The firmware handles '\t' internally, so stop trying to emulate it (which, incidentally, had a bug in it.) Fixes a really weird hang at bootup in rcu_bootup_announce, which, as far as I can tell, is the first printk in the core kernel to use a tab as the first character. Cc: stable@kernel.org Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-04Documentation: update broken web addresses.Justin P. Mattock138-330/+238
Below you will find an updated version from the original series bunching all patches into one big patch updating broken web addresses that are located in Documentation/* Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult, the best way to deal with these is to use web.archive.org to locate these addresses that are outdated. Now there are also some addresses pointing to .spec files some are located, but some(after searching on the companies site)where still no where to be found. In this case I just changed the address to the company site this way the users can contact the company and they can locate them for the users. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Thomas Weber <weber@corscience.de> Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Cc: Paulo Marques <pmarques@grupopie.com> Cc: Randy Dunlap <rdunlap@xenotime.net> Cc: Michael Neuling <mikey@neuling.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-08-04fix comment typo "choosed" -> "chosen"Uwe Kleine-König1-1/+1
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-08-04hostap:hostap_hw.c Fix typo in commentJustin P. Mattock1-1/+1
The patch below fixes a typo in a comment. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-08-04Fix spelling contorller -> controller in commentsStefan Weil2-2/+2
Cc: Jiri Kosina <trivial@kernel.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Weil <weil@mail.berlios.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-08-04amd64_edac: Minor formatting fixBorislav Petkov1-1/+1
EDAC MC3: CE page 0xc32281, offset 0x8a0, grain 0, syndrome 0x1, row 2, channel 1, label "": amd64_edac EDAC MC3: CE - no information available: amd64_edacError Overflow Add the missing space before "Error Overflow" on the second line. Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
2010-08-04amd64_edac: Fix operator precendence errorBorislav Petkov1-1/+1
The bitwise AND is of higher precedence, make that explicit. Cc: <stable@kernel.org> # 34.x Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
2010-08-03phy/marvell: add 88ec048 supportCyril Chemparathy1-0/+42
Marvell 88ec048 is a derivative of its 88e1121r device. From the programmer's perspective, the one major difference is the addition of an additional control bit in Page 2 Register 16 - used to control the padding of odd nibble preambles. This patch adds support for this new device, while inheriting as much code as possible from the existing 88e1121r implementation. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-03igb: Program MDICNFG register prior to PHY initAlexander Duyck1-7/+11
This patch addresses an issue seen on 82580 in which the MDICNFG register will be reset during a single function reset and as a result we will be unable to communicate with the PHY. To correct the issue, added a call to reset_mdicnfg just prior to the first access of the MDICNFG register in sgnii_uses_mdio. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-03e1000e: correct MAC-PHY interconnect register offset for 82579Bruce Allan1-1/+1
The MAC-PHY interconnect register set on ICH/PCH parts is accessed through a peephole mechanism by writing an offset to a CSR register. The offset for the interconnect's half-duplex control register (which is used in a jumbo frame workaround for 82579) is incorrect. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-03hso: Add new product IDFilip Aben1-0/+1
This patch adds a new product ID to the hso driver. Signed-off-by: Filip Aben <f.aben@option.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-03can: Add driver for esd CAN-USB/2 deviceMatthias Fuchs3-0/+1139
This patch adds a driver for esd's USB high speed CAN interface. The driver supports devices with multiple CAN interfaces. Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu> Acked-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-03[CPUFREQ] Remove pointless printk from p4-clockmod.Dave Jones1-6/+1
The only machines this is triggering on should be supported by acpi-cpufreq or acpi's internal throttling. Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] Fix section mismatch for powernow_cpu_init in powernow-k7.cHolger Freyther1-4/+4
Use __cpuinit instead of __init for the cpufreq_driver init function like it is done in powernow-k8.c. This is removing the warning generated when compiling with the CONFIG_DEBUG_SECTION_MISMATCH=y option. Signed-off-by: Holger Hans Peter Freyther <holger@moiji-mobile.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] Fix section mismatch for longhaul_cpu_init.Holger Freyther2-16/+16
Use __cpuinit instead of __init for the cpufreq_driver init function like it is done in powernow-k8.c. Use the __cpuinitdata for data used by the routines marked as __cpuinit. This is removing the warning generated when compiling with the CONFIG_DEBUG_SECTION_MISMATCH=y option. Signed-off-by: Holger Hans Peter Freyther <holger@moiji-mobile.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] Fix section mismatch for longrun_cpu_init.Holger Freyther1-3/+3
Use __cpuinit instead of __init for the cpufreq_driver init function like it is done in powernow-k8.c. This is removing the warning generated when compiling with the CONFIG_DEBUG_SECTION_MISMATCH=y option. Signed-off-by: Holger Hans Peter Freyther <holger@moiji-mobile.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] powernow-k8: Fix misleading variable namingBorislav Petkov1-2/+2
rdmsr() takes the lower 32 bits as a second argument and the high 32 as a third. Fix the names accordingly since they were swapped. There should be no functionality change resulting from this patch. Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)Peter Huewe1-6/+3
This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the PCI_VDEVICE macro, and thus improves readability. Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] arch/x86/kernel/cpu/cpufreq: use for_each_pci_dev()Kulikov Vasiliy1-1/+1
Use for_each_pci_dev() to simplify the code. Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] fix brace coding style issue.Neal Buckendahl1-2/+1
This patch fixes up a brace warning found by the checkpatch.pl tool Signed-off-by: Neal Buckendahl <nealb001@tbcnet.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] x86 cpufreq: Make trace_power_frequency cpufreq driver independentThomas Renninger6-25/+31
and fix the broken case if a core's frequency depends on others. trace_power_frequency was only implemented in a rather ungeneric way in acpi-cpufreq driver's target() function only. -> Move the call to trace_power_frequency to cpufreq.c:cpufreq_notify_transition() where CPUFREQ_POSTCHANGE notifier is triggered. This will support power frequency tracing by all cpufreq drivers trace_power_frequency did not trace frequency changes correctly when the userspace governor was used or when CPU cores' frequency depend on each other. -> Moving this into the CPUFREQ_POSTCHANGE notifier and pass the cpu which gets switched automatically fixes this. Robert Schoene provided some important fixes on top of my initial quick shot version which are integrated in this patch: - Forgot some changes in power_end trace (TP_printk/variable names) - Variable dummy in power_end must now be cpu_id - Use static 64 bit variable instead of unsigned int for cpu_id Signed-off-by: Thomas Renninger <trenn@suse.de> CC: davej@redhat.com CC: arjan@infradead.org CC: linux-kernel@vger.kernel.org CC: robert.schoene@tu-dresden.de Tested-by: robert.schoene@tu-dresden.de Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] acpi-cpufreq: Fix CPU_ANY CPUFREQ_{PRE,POST}CHANGE notificationThomas Renninger1-2/+2
Signed-off-by: Thomas Renninger <trenn@suse.de> CC: venki@google.com CC: davej@redhat.com CC: arjan@infradead.org CC: linux-kernel@vger.kernel.org Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] ondemand: don't synchronize sample rate unless multiple cpus presentJocelyn Falempe1-2/+6
For UP systems this is not required, and results in a more consistent sample interval. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Jocelyn Falempe <jocelyn.falempe@motorola.com> Signed-off-by: Mike Chan <mike@android.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] unexport (un)lock_policy_rwsem* functionsAmerigo Wang3-22/+3
lock_policy_rwsem_* and unlock_policy_rwsem_* functions are scheduled to be unexported when 2.6.33. Now there are no other callers of them out of cpufreq.c, unexport them and make them static. Signed-off-by: WANG Cong <amwang@redhat.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] ondemand: Refactor frequency increase codeMike Chan1-13/+12
Make simpler to read and call. *** v3 - Always call when powersave_bias is enabled. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Mike Chan <mike@android.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] powernow-k8: On load failure, remind the user to enable support in BIOS setupMarti Raudsepp1-0/+2
On Wed, 2010-01-20 at 16:56 +0100, Thomas Renninger wrote: > But most often this happens if people upgrade their CPU and do not > update their BIOS. > Or the vendor does not recognise the new CPU even if the BIOS got > updated. Maybe some of those people just didn't realize it was disabled in BIOS? If you tell users that it's a firmware bug then they'll probably just give up. > The itself message might be an enhancment, IMO it's not worth a patch. Why do you think so? I spent an hour on hunting down the BIOS upgrade, only to find that it didn't improve anything. It was a day later that I realized that it might be a BIOS option; and the option was literally the _last_ option in the whole BIOS setup. :) This message would have saved the day. > But do not revert the FW_BUG part! Sure, you have a point here. How about this patch?
2010-08-03[CPUFREQ] powernow-k8: Limit Pstate transition latency checkBorislav Petkov1-6/+5
The Pstate transition latency check was added for broken F10h BIOSen which wrongly contain a value of 0 for transition and bus master latency. Fam11h and later, however, (will) have similar transition latency so extend that behavior for them too. Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] Fix PCC driver error pathMatthew Garrett1-8/+9
The PCC cpufreq driver unmaps the mailbox address range if any CPUs fail to initialise, but doesn't do anything to remove the registered CPUs from the cpufreq core resulting in failures further down the line. We're better off simply returning a failure - the cpufreq core will unregister us cleanly if we end up with no successfully registered CPUs. Tidy up the failure path and also add a sanity check to ensure that the firmware gives us a realistic frequency - the core deals badly with that being set to 0. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] fix double freeing in error path of pcc-cpufreqDaniel J Blueman1-12/+6
Prevent double freeing on error path. Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] pcc driver should check for pcch method before calling _OSCMatthew Garrett1-1/+5
The pcc specification documents an _OSC method that's incompatible with the one defined as part of the ACPI spec. This shouldn't be a problem as both are supposed to be guarded with a UUID. Unfortunately approximately nobody (including HP, who wrote this spec) properly check the UUID on entry to the _OSC call. Right now this could result in surprising behaviour if the pcc driver performs an _OSC call on a machine that doesn't implement the pcc specification. Check whether the PCCH method exists first in order to reduce this probability. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] fix memory leak in cpufreq_add_devXiaotian Feng1-0/+1
We didn't free policy->related_cpus in error path err_unlock_policy. This is catched by following kmemleak report: unreferenced object 0xffff88022a0b96d0 (size 512): comm "modprobe", pid 886, jiffies 4294689177 (age 780.694s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8111ebe5>] create_object+0x186/0x281 [<ffffffff814fad4f>] kmemleak_alloc+0x60/0xa7 [<ffffffff8111127a>] kmem_cache_alloc_node_notrace+0x120/0x142 [<ffffffff81262e4f>] alloc_cpumask_var_node+0x2c/0xd7 [<ffffffff81262f0b>] alloc_cpumask_var+0x11/0x13 [<ffffffff81262f1c>] zalloc_cpumask_var+0xf/0x11 [<ffffffff8140fac0>] cpufreq_add_dev+0x11f/0x547 [<ffffffff81334bda>] sysdev_driver_register+0xc2/0x11d [<ffffffff8140e334>] cpufreq_register_driver+0xcb/0x1b8 [<ffffffffa032e040>] 0xffffffffa032e040 [<ffffffff810021ba>] do_one_initcall+0x5e/0x15c [<ffffffff81087f94>] sys_init_module+0xa6/0x1e6 [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by: Xiaotian Feng <dfeng@redhat.com> Cc: Thomas Renninger <trenn@suse.de> Cc: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03[CPUFREQ] revert "[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)"Andrej Gelenberg1-10/+1
395913d0b1db37092ea3d9d69b832183b1dd84c5 ("[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)") is not needed, because there is no rwsem lock in cpufreq_ondemand and cpufreq_conservative anymore. Lock should not be released until the work done. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=1594 Signed-off-by: Andrej Gelenberg <andrej.gelenberg@udo.edu> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-08-03PARISC: led.c - fix potential stack overflow in led_proc_write()Helge Deller1-2/+4
avoid potential stack overflow by correctly checking count parameter Reported-by: Ilja <ilja@netric.org> Signed-off-by: Helge Deller <deller@gmx.de> Acked-by: Kyle McMartin <kyle@mcmartin.ca> Cc: James E.J. Bottomley <jejb@parisc-linux.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-03ips driver: make it less chattyJesse Barnes1-2/+2
We don't need a dev_warn when we exceed a thermal or power limit as we'll handle it appropriately by clamping down on the CPU, GPU or both as needed. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-08-03edac, mc: Improve scrub rate handlingBorislav Petkov5-59/+46
Fortify the interface to not accept negative values, remove memctrl_int_store() as a result. Also, sanitize bandwidth setting by making the argument a simple u32 instead of strange u32 pointer being passed around for no obvious reason. Then, fix error handling and teach it to return proper error values. Finally, make code more readable, simplify debug messages. Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Arthur Jones <ajones@riverbed.com> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Acked-by: Doug Thompson <dougthompson@xmission.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.