| Age | Commit message (Collapse) | Author |
|---|
|
These structs have a "_pad" member. Also the "phw" structs have an 8
byte "hw_addr[]" array but sometimes only the first 6 bytes are
initialized.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
regcache_sync_block_raw_flush() expects the address of the register after last
register that needs to be synced as its parameter. But the last call to
regcache_sync_block_raw_flush() in regcache_sync_block_raw() passes the address
of the last register in the block. This effectively always skips over the last
register in a block, even if it needs to be synced. In order to fix it increase
the address by one register.
The issue was introduced in commit 75a5f89 ("regmap: cache: Write consecutive
registers in a single block write").
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
As comment in include/uapi/asm-generic/fcntl.h described, when
introducing new O_* bits, we need to check its uniqueness in
fcntl_init(). But __O_TMPFILE bit is missing. So fix it.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Every now and then someone proposes a new flink syscall, and this spawns
a long discussion of whether it would be a security problem. I think
that this is missing the point: flink is *already* allowed without
privilege as long as /proc is mounted -- it's called AT_SYMLINK_FOLLOW.
Now that O_TMPFILE is here, the ability to create a file with O_TMPFILE,
write it, and link it in is very convenient. The only problem is that
it requires that /proc be mounted so that you can do:
linkat(AT_FDCWD, "/proc/self/fd/<tmpfd>", dfd, path, AT_SYMLINK_NOFOLLOW)
This sucks -- it's much nicer to do:
linkat(tmpfd, "", dfd, path, AT_EMPTY_PATH)
Let's allow it.
If this turns out to be excessively scary, it we could instead require
that the inode in question be I_LINKABLE, but this seems pointless given
the /proc situation
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
O_TMPFILE, like O_CREAT, should respect the requested mode and should
create regular files.
This fixes two bugs: O_TMPFILE required privilege (because the mode
ended up as 000) and it produced bogus inodes with no type.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Since remove_proc_entry() started to wait for IO in progress (i.e.
since 2007 or so), the locking in fs/reiserfs/proc.c became wrong;
if procfs read happens between the moment when umount() locks the
victim superblock and removal of /proc/fs/reiserfs/<device>/*,
we'll get a deadlock - read will wait for s_umount (in sget(),
called by r_start()), while umount will wait in remove_proc_entry()
for that read to finish, holding s_umount all along.
Fortunately, the same change allows a much simpler race avoidance -
all we need to do is remove the procfs entries in the very beginning
of reiserfs ->kill_sb(); that'll guarantee that pointer to superblock
will remain valid for the duration for procfs IO, so we don't need
sget() to keep the sucker alive. As the matter of fact, we can
get rid of the home-grown iterator completely, and use single_open()
instead.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
The hardware interrupt routing for boot CPU != 0 is wrong because it
will route all the hardware interrupts to TP0 which is not the one we
booted from. Fix this by properly checking which boot CPU we are booting
from and updating the right interrupt mask for the boot CPU. This fixes
booting on BCM3368 with bmips_smp_emabled = 0.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Cc: jogo@openwrt.org
Cc: cernekee@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/5650/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
current_cpu_type() is not preemption-safe.
If CONFIG_PREEMPT is enabled then mipsxx_reg_setup() can be called from preemptible state.
Added get_cpu()/put_cpu() pair to make it preemption-safe.
This was found while testing oprofile with CONFIG_DEBUG_PREEMPT enable.
/usr/zntestsuite # opcontrol --init
/usr/zntestsuite # opcontrol --setup --event=L2_CACHE_ACCESSES:500 --event=L2_CACHE_MISSES:500 --no-vmlinux
/usr/zntestsuite # opcontrol --start
Using 2.6+ OProfile kernel interface.
BUG: using smp_processor_id() in preemptible [00000000] code: oprofiled/1362
caller is mipsxx_reg_setup+0x11c/0x164
CPU: 0 PID: 1362 Comm: oprofiled Not tainted 3.10.4 #18
Stack : 00000006 70757465 00000000 00000000 00000000 00000000 80b173f6 00000037
80b10000 00000000 80b21614 88f5a220 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 89c49c00 89c49c2c 80721254 807b7927 8012c1d0
80b10000 80721254 00000000 00000552 88f5a220 80b1335c 807b78e6 89c49ba8
...
Call Trace:
[<801099a4>] show_stack+0x64/0x7c
[<80665520>] dump_stack+0x20/0x2c
[<803a2250>] debug_smp_processor_id+0xe0/0xf0
[<8052df24>] mipsxx_reg_setup+0x11c/0x164
[<8052cd70>] op_mips_setup+0x24/0x4c
[<80529cfc>] oprofile_setup+0x5c/0x12c
[<8052b9f8>] event_buffer_open+0x78/0xf8
[<801c3150>] do_dentry_open.isra.15+0x2b8/0x3b0
[<801c3270>] finish_open+0x28/0x4c
[<801d49b8>] do_last.isra.41+0x2cc/0xd00
[<801d54a0>] path_openat+0xb4/0x4c4
[<801d5c44>] do_filp_open+0x3c/0xac
[<801c4744>] do_sys_open+0x110/0x1f4
[<8010f47c>] stack_done+0x20/0x44
Bug reported and original patch by Jerin Jacob <jerinjacobk@gmail.com>.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Jerin Jacob <jerinjacobk@gmail.com>
|
|
The PNX8335_PCI_ETHERNET_INT macro is defined in
arch/mips/include/asm/mach-pnx833x/irq-mapping.h
only if CONFIG_SOC_PNX8335 is selected.
Fixes the following randconfig problem:
arch/mips/pnx833x/common/platform.c:210:12:
error: 'PNX8335_PIC_ETHERNET_INT' undeclared here
(not in a function)
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5585/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
When CONFIG_PREEMPT is enabled, Linux will not be able to boot and warn:
[ 4.127825] ------------[ cut here ]------------
[ 4.133376] WARNING: at init/main.c:699 do_one_initcall+0x150/0x158()
[ 4.140738] initcall xen_init_events+0x0/0x10c returned with preemption imbalance
This is because xen_percpu_init uses get_cpu but doesn't have the corresponding
put_cpu.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
|
|
3cc8e40e8ff8e232a9dd672da81beabd09f87366
"xen/arm: rename xen_secondary_init and run it on every online cpu"
The commit is in v3.10-rc2, the current branch is based on v3.10-rc1.
|
|
John McCalpin reports that the "drs_data" and "ncb_data" QPI
uncore events are missing the "extra bit" and always return zero
values unless the bit is properly set.
More details from him:
According to the Xeon E5-2600 Product Family Uncore Performance
Monitoring Guide, Table 2-94, about 1/2 of the QPI Link Layer events
(including the ones that "perf" calls "drs_data" and "ncb_data") require
that the "extra bit" be set.
This was confusing for a while -- a note at the bottom of page 94 says
that the "extra bit" is bit 16 of the control register.
Unfortunately, Table 2-86 clearly says that bit 16 is reserved and must
be zero. Looking around a bit, I found that bit 21 appears to be the
correct "extra bit", and further investigation shows that "perf" actually
agrees with me:
[root@c560-003.stampede]# cat /sys/bus/event_source/devices/uncore_qpi_0/format/event
config:0-7,21
So the command
# perf -e "uncore_qpi_0/event=drs_data/"
Is the same as
# perf -e "uncore_qpi_0/event=0x02,umask=0x08/"
While it should be
# perf -e "uncore_qpi_0/event=0x102,umask=0x08/"
I confirmed that this last version gives results that agree with the
amount of data that I expected the STREAM benchmark to move across the QPI
link in the second (cross-chip) test of the original script.
Reported-by: John McCalpin <mccalpin@tacc.utexas.edu>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Cc: zheng.z.yan@intel.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1308021037280.26119@vincent-weaver-1.um.maine.edu
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Add some necessary braces that have been removed during driver cleanup.
This fixes the I2C prescaler calculation.
Signed-off-by: Michael Brunner <michael.brunner@kontron.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Recently we have been seing some reports about PIO mode not working properly.
- http://www.spinics.net/lists/linux-i2c/msg11985.html
- http://marc.info/?l=linux-i2c&m=137235593101385&w=2
- https://lkml.org/lkml/2013/6/24/430
Let's use DMA mode even for small transfers.
Without this patch, i2c reads the incorrect sgtl5000 version on a mx28evk when
touchscreen is enabled:
[ 5.856270] sgtl5000 0-000a: Device with ID register 0 is not a sgtl5000
[ 9.877307] sgtl5000 0-000a: ASoC: failed to probe CODEC -19
[ 9.883528] mxs-sgtl5000 sound.12: ASoC: failed to instantiate card -19
[ 9.892955] mxs-sgtl5000 sound.12: snd_soc_register_card failed (-19)
Cc: <stable@vger.kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Marek Vasut <marex@denx.de>
[wsa: we have a proper solution for -next, so this non intrusive
solution is OK for now]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
The following is needed as well to fix warning/error about shifting a 32 bit
value 32 bits which occurs if building on 32 bit platform caused by conversion
to using dma_addr_t
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
Second round of IIO fixes for the 3.11 cycle.
1) Fix a long term race in the IIO trigger handling.
This only effects cases where a single trigger is in use
by multiple devices.
2) ti_am335x fix an issue with incorrect data due to reading before
the sequencer is finished.
|
|
There are several drivers in drivers/net/usb/ that
do not have specific MAINTAINERS that should have
emails forwarded to the linux-usb mailing list.
Add a section for those drivers.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
Sarah writes:
xhci: Misc bug fixes for 3.11.
Hi Greg,
Here's two small fixes for 3.11. The first patch fixes a 5 second hang in
khubd after a USB device disconnect on some xHCI hosts. The second fixes a
build warning.
Sarah Sharp
|
|
When renaming ll_poll to busy poll, I introduced a typo
in the name of the do-nothing placeholder for sk_busy_loop
and called it sk_busy_poll.
This broke compile when busy poll was not configured.
Cong Wang submitted a patch to fixed that.
This patch removes the now redundant, misspelled placeholder.
Signed-off-by: Eliezer Tamir <eliezer.tamir@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This old driver never checked for DMA mapping errors.
Causing splats with the new DMA mapping checks:
WARNING: at lib/dma-debug.c:937 check_unmap+0x47b/0x930()
skge 0000:01:09.0: DMA-API: device driver failed to check map
Add checks and unwind code.
Reported-by: poma <pomidorabelisima@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If the _BCL package ordering is descending, the first level
(br->levels[2]) is likely to be 0, and if the number of levels
matches the number of steps, we might confuse a returned level to
mean the index.
For example:
current_level = max_level = 100
test_level = 0
returned level = 100
In this case 100 means the level, not the index, and _BCM failed.
Still, if the _BCL package ordering is descending, the index of
level 0 is also 100, so we assume _BQC is indexed, when it's not.
This causes all _BQC calls to return bogus values causing weird
behavior from the user's perspective. For example:
xbacklight -set 10; xbacklight -set 20;
would flash to 90% and then slowly down to the desired level (20).
The solution is simple; test anything other than the first level
(e.g. 1).
[rjw: Changelog]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This was missed when splitting out the phy from the controller node in
commit 9dffe3be3f32 (ARM: tegra: modify ULPI reset GPIO properties).
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
|
|
This patch removes sti_secondary_start from _INIT section, there are 2
reason for this removal.
1. discarding such a small code does not save much, given the RAM
sizes.
2. Having this code discarded, creates corruption issue when we boot
smp-kernel with nrcpus=1 or with single cpu node in DT.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
This patch fixes cpu nodes with device_type = "cpu". This change was not
necessary before 3.10-rc7.
Without this patch STi SOCs does not boot as SMP.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
From Simon Horman:
Second round of Renesas ARM based SoC fixes for v3.11
* Lager board: do not annotate gpio_buttons as __initdata
- This avoids accessing uninitialised memory if keys are pressed
after kernel initialisation completes.
- Bug introduced in gpio-keys were enabled in v3.11-rc1
* Bock-W board: fix SDHI0 PFC settings
- Allow detection of SD card
- Bug introduced in SDHI support was added in v3.11-rc1
* shdma: fixup sh_dmae_get_partial() calculation error
- Bug introduced in 2.6.34-rc1.
* armadillo800eva board: Don't request GPIO 166 in board code
- Allow use of touchscreen
- Bug introduced in v3.11-rc1
* tag 'renesas-fixes2-for-v3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: lager: do not annotate gpio_buttons as __initdata
ARM: shmobile: BOCK-W: fix SDHI0 PFC settings
shdma: fixup sh_dmae_get_partial() calculation error
ARM: shmobile: armadillo800eva: Don't request GPIO 166 in board code
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes
From Paul Walmsley via Tony Lindgren:
Some OMAP hwmod fixes for v3.11-rc. Mostly intended to fix an earlyprintk
regression and an AM33xx cpgmac power management regression.
Basic build, boot, and PM tests are available here:
http://www.pwsan.com/omap/testlogs/hwmod_fixes_a_v3.11-rc/20130730042132/
The tests include temporary fixes for the unrelated 2430SDP and OMAP3
boot regressions, which are not part of this signed tag.
* tag 'for-v3.11-rc/omap-fixes-b' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending:
ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space
ARM: OMAP2+: hwmod: rt address space index for DT
ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state
ARM: OMAP2+: Avoid idling memory controllers with no drivers
ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren:
Fixes for omap5-uevm regulators from Nishanth Menon <nm@ti.com>:
Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
series is based power tree on production board 750-2628-XXX platform.
Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
supply hardware blocks at voltages that are out of specification.
There is a chance that without these fixes there can be hardware
damage to omap5-uevm boards with the v3.11-rc series.
* tag 'omap-for-v3.11/fixes-omap5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: omap5-uevm: update optional/unused regulator configurations
ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
ARM: dts: omap5-uevm: document regulator signals used on the actual board
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm into fixes
From David Brown, fixes for MSM for 3.11:
Two small fixes for MSM.
The first fixes the a gpio controller register address. I didn't see
any acks from the devicetree maintainers, so I've copied them on this
pull request. The change itself is minor, and just to the register
address.
The second change removes the gpiomux V1 code from MSM. This was
breaking compilation for some of the targets.
* tag 'msm-3.11-fix1' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm:
ARM: msm: Consolidate gpiomux for older architectures
ARM: msm: dts: Fix the gpio register address for msm8960
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The PTE layouts are the same for both ppgtt and gtt, so we can simplify
the setup for ppgtt by copying the encoding function pointer from gtt.
This prevents bugs where we update one function pointer, but forget the
other.
For instance,
commit 4d15c145a6234d999c0452eec0d275c1fbf0688c
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Thu Jul 4 11:02:06 2013 -0700
drm/i915: Use eLLC/LLC by default when available
only extends the gtt to use eLLC/LLC cacheing and forgets to also update
the ppgtt function pointer.
v2: Actually mention the bug being fixed (Kenneth)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Almost invariably the reason why FBC cannot be turned on is the same
every time (disabled via parameter, too many pipes, pipe too large etc)
as modesetting and framebuffer configuration changes less frequently
than trying to enable FBC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
In the old days of the crtc helpers we've only had the encoder and
crtc ->mode_fixup callbacks. So when the lvds connector wanted to
adjust the crtc timings it had to set a driver-private mode flag to
tell the crtc mode fixup code to not overwrite them with the generic
ones.
When converting things to the new infrastructure I've kept the entire
logic and only moved the flag to pipe_config->timings_set. But this
logic is pretty tricky and already caused regressions:
commit 21d8a4756af5fdf4a42e79a77cf3b6f52678d443
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 12 08:07:30 2013 +0200
drm/i915: fix pfit regression for non-autoscaled resolutions
So take advantage of the flexibility our own modeset infrastructure
affords us and prefill default crtc timings. This allows us to rip out
->timings_set. Note that we overwrite things again when retrying the
pipe config computation due to bandwidth constraints to avoid bogus
crtc timings if the encoder only does relative adjustments (which is
how the pfit code works). Only a theoretical concern though since
platforms where we retry (pch-split platforms) do not need
adjustements (since only the old gmch pfit needs that). But let's
better be safe than sorry.
Since we now initialize the crtc timings before calling the
encoder->compute_config functions the crtc initialization in the gmch
pfit code is now redudant and so can be removed.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add a paragraph to the commit message to explain why we can
ditch the crtc timings initialization call from the gmch pfit code, to
answer a question from Rodrigo's review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The encoder->mode_set callback from the crtc helpers is now completely
unused in our driver. Good riddance!
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Same conversion as for hdmi/dp.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Does nothing, so trivial conversion. But update the outdated comment
while at it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Usual drill applies. Again I've not switched the upcast helpers to use
intel_encoder instead of drm_encoder since that's much more invasive
and will change also the hdmi and ddi encoders.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Again drop the intel_ prefix from the intel_crtc local variable to
save a bit of space. But here I didn't switch the upcast macros to
intel_encoder since all our infoframe interfaces still use
drm_encoder. That needs to be changed first.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Also drop the intel_ prefix from the local intel_crtc variable and
reorder the upcast macros a bit for more reuse.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Also switch to intel_encoder for the upcast helper while at it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
It's what all callers (except for the destroy callback which is called
from drm core) actually want.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Everyone is now using our own ->compute_config callback, which means
we can now also make that callback mandatory.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This is the last encoder ->mode_fixup callback we have left, so
convert it.
Note that we want to only rip out the encoder->mode_fixup callback.
But we still have the dvo_slave->mode_fixup callback. dvo is gen2
only, so we won't ever touch this again. Hence why I didn't go through
all 6-7 dvo slave drivers and give them the same treatment. I'll add a
note to the commit message about this when merging, presuming there's
nothing else in the patch that needs to be fixed up.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add note about why we keep the dvo->mode_fixup callback to
answer a question from Rodrigo's review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
More natural and will soon be even better!
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Fixes regression from
commit 4906557eb37b7fef84fad4304acef6dedf919880
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date: Thu Jul 11 18:45:05 2013 -0300
drm/i915: Hook PSR functionality
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67526
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Pull dmaengine fixes from Vinod Koul:
"Two fixes for slave dmaengine. The first fixes cyclic dma transfers
for pl330 and the second one makes us return the correct error code on
probe"
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
dma: pl330: Fix cyclic transfers
pch_dma: fix error return code in pch_dma_probe()
|
|
Pull drm fix from Dave Airlie:
"Just a quick fix that a few people have reported, be nice to have in
asap"
The drm tree seems to be very confused about 64-bit divides. Here it
uses a slow 64-by-64 bit divide to divide by a small constant. Oh well.
Doesn't look performance-critical, just stupid.
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: fix 64 bit divide in SI spm code
|
|
Commit 46a1c2c7ae53 ("vfs: export lseek_execute() to modules") broke the
tmpfs SEEK_DATA/SEEK_HOLE implementation, because vfs_setpos() converts
the carefully prepared -ENXIO to -EINVAL. Other filesystems avoid it in
error cases: do the same in tmpfs.
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Jie Liu <jeff.liu@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"All small regression or small fixes, nothing surprising at this stage.
- regression fix for intel Mac Mini quirk
- compress ioctl error fix
- ASoC fixes for control change notifications, some UI fixes,
driver-specific fixes (resource leak, build errors, etc)"
* tag 'sound-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix missing fixup for Mac Mini with STAC9221
ASoC: wm0010: Fix resource leak
ASoC: au1x: Fix build
ASoC: bf5xx-ac97: Fix compile error with SND_BF5XX_HAVE_COLD_RESET
ASoC: bfin-ac97: Fix prototype error following AC'97 refactoring
ALSA: compress: fix the return value for SNDRV_COMPRESS_VERSION
ASoC: dapm: Fix return value of snd_soc_dapm_put_{volsw,enum_virt}()
|
