- 03 6月, 2010 6 次提交
-
-
由 Wolfram Sang 提交于
I2C drivers can use the clientdata-pointer to point to private data. As I2C devices are not really unregistered, but merely detached from their driver, it used to be the drivers obligation to clear this pointer during remove() or a failed probe(). As a couple of drivers forgot to do this, it was agreed that it was cleaner if the i2c-core does this clearance when appropriate, as there is no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. This feature was added to the core with commit e4a7b9b0 to fix the faulty drivers. As there is no need anymore to clear the clientdata-pointer, remove all current occurrences in the drivers to simplify the code and prevent confusion. Signed-off-by: NWolfram Sang <w.sang@pengutronix.de> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Acked-by: NRichard Purdie <rpurdie@linux.intel.com> Acked-by: NDmitry Torokhov <dtor@mail.ru> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
由 Wolfram Sang 提交于
And fix a typo while we are here Signed-off-by: NWolfram Sang <w.sang@pengutronix.de> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
由 Jean Delvare 提交于
Otherwise it's not clear what it is checking. Also move the function to save a forward declaration. Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
由 Jean Delvare 提交于
Move strict I2C address validity check to a single function, and document the reserved I2C addresses there. Signed-off-by: NJean Delvare <khali@linux-fr.org> Cc: Hans Verkuil <hverkuil@xs4all.nl>
-
由 Jean Delvare 提交于
Do basic address validity checks when a client is being registered. We already had checks in place for devices which are being detected, but not for devices which are simply instantiated. This is a very basic check. We don't want to do strict checking here because some devices are known to infringe the I2C address constraints (e.g. IR receivers at 7-bit address 0x7a while this value is supposedly reserved for 10-bit addresses.) So we assume the caller knows what it is doing. Signed-off-by: NJean Delvare <khali@linux-fr.org> Cc: Matthieu Castet <castet.matthieu@free.fr>
-
由 Jean Delvare 提交于
Use the same I2C device presence detection code for legacy and new device detection functions. This is more consistent and makes the code smaller. Signed-off-by: NJean Delvare <khali@linux-fr.org> Cc: Matthieu Castet <castet.matthieu@free.fr>
-
- 02 6月, 2010 2 次提交
-
-
由 Zou Nan hai 提交于
This will let userland only try to use the new media decode functionality when the appropriate kernel is present. Signed-off-by: NZou Nan hai <nanhai.zou@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Adam Jackson 提交于
I'm actually kind of shocked that it works at all otherwise. Signed-off-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 01 6月, 2010 7 次提交
-
-
由 Alan Cox 提交于
Commands with data must set the length in the message. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Julia Lawall 提交于
The function inittiger is only called from nj_init_card, where a lock is held. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @gfp exists@ identifier fn; position p; @@ fn(...) { ... when != spin_unlock_irqrestore when any GFP_KERNEL@p ... when any } @locked@ identifier gfp.fn; @@ spin_lock_irqsave(...) ... when != spin_unlock_irqrestore fn(...) @depends on locked@ position gfp.p; @@ - GFP_KERNEL@p + GFP_ATOMIC // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Denis Kirjanov 提交于
Add missing validate_addr hook Signed-off-by: NDenis Kirjanov <dkirjanov@kernel.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Denis Kirjanov 提交于
Convert TX hook to netdev_tx_t type Signed-off-by: NDenis Kirjanov <dkirjanov@kernel.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael S. Tsirkin 提交于
virtio-net bounces buffer allocations off to a thread if it can't allocate buffers from the atomic pool. However, if posting buffers still requires atomic buffers, this is unlikely to succeed. Fix by passing in the proper gfp_t parameter. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sathya Perla 提交于
The current code fails on ppc as hdr.timeout is not being converted to le32. Signed-off-by: NSathya Perla <sathyap@serverengines.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Anatolij Gustschin 提交于
Fixes build error caused by the OF device_node pointer being moved into struct device. Signed-off-by: NAnatolij Gustschin <agust@denx.de> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 31 5月, 2010 2 次提交
-
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Randy Dunlap 提交于
Fix a bunch of new rapidio kernel-doc warnings: Warning(include/linux/rio.h:123): No description found for parameter 'comp_tag' Warning(include/linux/rio.h:123): No description found for parameter 'phys_efptr' Warning(include/linux/rio.h:123): No description found for parameter 'em_efptr' Warning(include/linux/rio.h:123): No description found for parameter 'pwcback' Warning(include/linux/rio.h:247): No description found for parameter 'set_domain' Warning(include/linux/rio.h:247): No description found for parameter 'get_domain' Warning(drivers/rapidio/rio-scan.c:1133): No description found for parameter 'rdev' Warning(drivers/rapidio/rio-scan.c:1133): Excess function parameter 'port' description in 'rio_init_em' Warning(drivers/rapidio/rio.c:349): No description found for parameter 'rdev' Warning(drivers/rapidio/rio.c:349): Excess function parameter 'mport' description in 'rio_request_inb_pwrite' Warning(drivers/rapidio/rio.c:393): No description found for parameter 'port' Warning(drivers/rapidio/rio.c:393): No description found for parameter 'local' Warning(drivers/rapidio/rio.c:393): No description found for parameter 'destid' Warning(drivers/rapidio/rio.c:393): No description found for parameter 'hopcount' Warning(drivers/rapidio/rio.c:393): Excess function parameter 'rdev' description in 'rio_mport_get_physefb' Warning(drivers/rapidio/rio.c:845): Excess function parameter 'local' description in 'rio_std_route_clr_table' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Cc: Alexandre Bounine <alexandre.bounine@idt.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 29 5月, 2010 23 次提交
-
-
由 Dan Carpenter 提交于
This fixes some sparse warnings: drivers/net/benet/be_cmds.c:1503:12: warning: function 'be_cmd_enable_magic_wol' with external linkage has definition drivers/net/benet/be_cmds.c:1668:12: warning: function 'be_cmd_get_seeprom_data' with external linkage has definition Signed-off-by: NDan Carpenter <error27@gmail.com> Acked-by: NSarveshwar Bandi <sarveshwarb@serverengines.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
The unlock accidentally got removed from the error path in dd131e76: "be2net: Bug fix to avoid disabling bottom half during firmware upgrade." Signed-off-by: NDan Carpenter <error27@gmail.com> Acked-by: NSarveshwar Bandi <sarveshwarb@serverengines.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Julia Lawall 提交于
Add a spin_unlock missing on the error path. The return value of write_reg seems to be completely ignored, so it seems that the lock should be released in every case. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression E1; @@ * spin_lock(E1,...); <+... when != E1 if (...) { ... when != E1 * return ...; } ...+> * spin_unlock(E1,...); // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mark Ware 提交于
This patch fixes an occasional transmit lockup in the mac-fcc which occurs after a tx error. The test scenario had the local port set to autoneg and the other end fixed at 100FD, resulting in a large number of late collisions. According to the MPC8280RM 30.10.1.3 (also 8272RM 29.10.1.3), after a tx error occurs, TBPTR may sometimes point beyond BDs still marked as ready. This patch walks back through the BDs and points TBPTR to the earliest one marked as ready. Tested on a custom board with a MPC8280. Signed-off-by: NMark Ware <mware@elphinstone.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dave Airlie 提交于
airlied -> brown paper bag. I blame Hi-5 or the Wiggles for lowering my IQ, move the fix inside some brackets instead of breaking everything in site. Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Venkatesh Pallipadi 提交于
acpi pad driver kind of aggressively marks TSC as unstable at init time, on mwait capable and non X86_FEATURE_NONSTOP_TSC systems. This is irrespective of whether pad driver is ever going to be used on the system or deep C-states are supported/used. This will affect every user who just happens to compile in (or get a kernel version which compiles in) acpi pad driver. Move mark_tsc_unstable() out of init to the actual idle invocation path of the pad driver. There is also another bug/missing_feature in the code that it does not support 'always running apic timer' and switches to broadcast mode unconditionally. Shaohua, can you take a look at that please. Signed-off-by: NVenkatesh Pallipadi <venki@google.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Andrea Gelmini 提交于
drivers/acpi/sleep.h:3: WARNING: space prohibited between function name and open parenthesis '(' Signed-off-by: NAndrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Venkatesh Pallipadi 提交于
acpi_enter_[simple,bm] does idle timing in ns, convert it to timeval, then to us, then to pmtimer_ticks and then back to ns. This patch changes things to idle timing in ns, convert it to us, and then to pmtimer_ticks. Just saves an imul along this path, but makes the code cleaner. Signed-off-by: NVenkatesh Pallipadi <venki@google.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Len Brown 提交于
This EXPERIMENTAL driver supersedes acpi_idle on Intel Atom Processors, Intel Core i3/i5/i7 Processors and associated Intel Xeon processors. It does not support the Intel Core2 processor or earlier. For kernels configured with ACPI, CONFIG_INTEL_IDLE=y allows intel_idle to probe before the ACPI processor driver. Booting with "intel_idle.max_cstate=0" disables intel_idle and the system will fall back on ACPI's "acpi_idle". Typical Linux distributions load ACPI processor module early, making CONFIG_INTEL_IDLE=m not easily useful on ACPI platforms. intel_idle probes all processors at module_init time. Processors that are hot-added later will be limited to using C1 in idle. Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhenyu Wang 提交于
With splitted engines on Sandybridge, each engine has its own interrupt control as well. This unmasks the interrupt to properly enable pipe control notify event for render engine. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhenyu Wang 提交于
Sandybridge(Gen6) has new format for PIPE_CONTROL command, the flush and post-op control are in dword 1 now. This changes command length field for difference between Ironlake and Sandybridge. I tried to test this with noop request and issue PIPE_CONTROL command for each sequence and track notify interrupts, which seems work fine. Hopefully we don't need workaround like on Ironlake for Sandybridge. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Since we now get_user_pages() outside of the mutex prior to performing the copy, we kmap() the page inside the copy routine and so need to perform an ordinary memcpy() and not copy_from_user(). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
As we do not have a requirement to be atomic and avoid sleeping whilst performing the slow copy for shmem based pread and pwrite, we can use kmap instead, thus simplifying the code. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
We can avoid an early clflush when pwriting if we use the current CPU write domain rather than moving the object to the GTT domain for the purposes of the pwrite. This has the advantage of not flushing the presumably hot data that we want to upload into the bo, and of ascribing the clflush to the execution when profiling. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
The callers expect us to cleanup any partially initialised structures before reporting the error. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Len Brown 提交于
commit d306ebc2 (ACPI: Be in TS_POLLING state during mwait based C-state entry) fixed an important power & performance issue where ACPI c2 and c3 C-states were clearing TS_POLLING even when using MWAIT (ACPI_STATE_FFH). That bug had been causing us to receive redundant scheduling interrups when we had already been woken up by MONITOR/MWAIT. Following up on that... In the MWAIT case, we don't have to subsequently check need_resched(), as that c heck was there for the TS_POLLING-clearing case. Note that not only does the cpuidle calling function already check need_resched() before calling us, the low-level entry into monitor/mwait calls it twice -- guaranteeing that a write to the trigger address can not go un-noticed. Also, in this case, we don't have to set TS_POLLING when we wake, because we never cleared it. Signed-off-by: NLen Brown <len.brown@intel.com> Acked-by: NVenkatesh Pallipadi <venki@google.com>
-
由 Christoph Fritz 提交于
Ethernet driver b44 does register ssb by it's pcihost_wrapper and doesn't set ssb_chipcommon. A check on this value introduced with commit d53cdbb9 and ea2db495 triggers: BUG: unable to handle kernel NULL pointer dereference at 00000010 IP: [<c1266c36>] ssb_is_sprom_available+0x16/0x30 Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Chris Wilson 提交于
If the object is bigger than the entire aperture, reject it early before evicting everything in a vain attempt to find space. v2: Use E2BIG as suggested by Owain G. Ainsworth. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
This particular warning is harmless as we emit during the normal pinning process where the batch buffer requires more fences than is available without eviction. Only if we fail to evict enough fences does this become a problem, so include the requested number of fences in the ultimate *error* message. v2: Remember to compile test even trial patches to remove warnings. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Whilst pinning the buffer, check that that its current alignment matches the requested alignment. If it does not, rebind. This should clear up any final render errors whilst resuming, for reference: Bug 27070 - [i915] Page table errors with empty ringbuffer https://bugs.freedesktop.org/show_bug.cgi?id=27070 Bug 15502 - render error detected, EIR: 0x00000010 https://bugzilla.kernel.org/show_bug.cgi?id=15502 Bug 13844 - i915 error: "render error detected" https://bugzilla.kernel.org/show_bug.cgi?id=13844Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Add the pitch that we about to write into the control register along with the base, offset and coordinates that go into the other control registers. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
If the FBC is already disabled, then we do not even attempt to disable FBC and so there is no point emitting a debug statement at that point, having already emitted one saying why we are disabling FBC. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-