Neaten code style in get_int().
Also use sizeof() instead of hard coded number as suggested by
Joe Perches <joe@perches.com>.
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
We normally allow the owner of a file to override permissions checks on
IO operations, since:
- the client will take responsibility for doing an access check
on open;
- the permission checks offer no protection against malicious
clients--if they can authenticate as the file's owner then
they can always just change its permissions;
- checking permission on each IO operation breaks the usual
posix rule that permission is checked only on open.
However, we've never allowed the owner to override permissions on
readdir operations, even though the above logic would also apply to
directories. I've never heard of this causing a problem, probably
because a) simultaneously opening and creating a directory (with
restricted mode) isn't possible, and b) opening a directory, then
chmod'ing it, is rare.
Our disallowal of owner-override on directories appears to be an
accident, though--the readdir itself succeeds, and then we fail just
because lookup_one_len() calls in our filldir methods fail.
I'm not sure what the easiest fix for that would be. For now, just make
this behavior obvious by denying the override right at the start.
This also fixes some odd v4 behavior: with the rdattr_error attribute
requested, it would perform the readdir but return an ACCES error with
each entry.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
We don't need to keep openowners around in the >=4.1 case, because they
aren't needed to handle CLOSE replays any more (that's a problem for
sessions). And doing so causes unexpected failures on a subsequent
destroy_clientid to fail.
We probably also need something comparable for lock owners on last
unlock.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Actually, xfs and jfs can optionally be case insensitive; we'll handle
that case in later patches.
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Share a little common logic. And note the comments here are a little
out of date (e.g. we don't always create new state in the "new" case any
more.)
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
For the most part readers of cl_cb_state only need a value that is
"eventually" right. And the value is set only either 1) in response to
some change of state, in which case it's set to UNKNOWN and then a
callback rpc is sent to probe the real state, or b) in the handling of a
response to such a callback. UNKNOWN is therefore always a "temporary"
state, and for the other states we're happy to accept last writer wins.
So I think we're OK here.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
According to RFC 5661, the TEST_STATEID operation is not allowed to
return NFS4ERR_STALE_STATEID. In addition, RFC 5661 says:
15.1.16.5. NFS4ERR_STALE_STATEID (Error Code 10023)
A stateid generated by an earlier server instance was used. This
error is moot in NFSv4.1 because all operations that take a stateid
MUST be preceded by the SEQUENCE operation, and the earlier server
instance is detected by the session infrastructure that supports
SEQUENCE.
I triggered NFS4ERR_STALE_STATEID while testing the Linux client's
NOGRACE recovery. Bruce suggested an additional test that could be
useful to client developers.
Lastly, RFC 5661, section 18.48.3 has this:
o Special stateids are always considered invalid (they result in the
error code NFS4ERR_BAD_STATEID).
An explicit check is made for those state IDs to avoid printk noise.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Initiate a CB probe when a new connection with the correct direction is added
to a session (IFF backchannel is marked as down). Without this a
BIND_CONN_TO_SESSION has no effect on the internal backchannel state, which
causes the server to reply to every SEQUENCE op with the
SEQ4_STATUS_CB_PATH_DOWN flag set until DESTROY_SESSION.
Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Pull hwmon subsystem fixes from Jean Delvare.
* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
hwmon: (coretemp) Drop needless initialization
hwmon: (coretemp) Document TjMax for 3rd generation i5/i7 processors
hwmon: (coretemp) Improve support for TjMax detection on Atom CPUs
hwmon: (coretemp) Add support for Atom D2000 and N2000 series CPU models
hwmon: (coretemp) Improve support of recent Atom CPU models
The asm-generic/bug.h __ASSEMBLY__ guarding is completely bogus, which
tripped up the powerpc build when the kernel.h include was added:
In file included from include/asm-generic/bug.h:5:0,
from arch/powerpc/include/asm/bug.h:127,
from arch/powerpc/kernel/head_64.S:31:
include/linux/kernel.h:44:0: warning: "ALIGN" redefined [enabled by default]
include/linux/linkage.h:57:0: note: this is the location of the previous definition
include/linux/sysinfo.h: Assembler messages:
include/linux/sysinfo.h:7: Error: Unrecognized opcode: `struct'
include/linux/sysinfo.h:8: Error: Unrecognized opcode: `__kernel_long_t'
Moving the __ASSEMBLY__ guard up and stashing the kernel.h include under
it fixes this up, as well as covering the case the original fix was
attempting to handle.
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When the READABLE_ASM cc-option tests were added they were done so prior
to the arch Makefile include, resulting in cc-option being run on the
host cc instead of the factoring in the cross prefix set up by the
architecture.
This bumps the include back up so that cc-option actually runs on the
compiler that we're building with.
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge hfsplus fixes from Christoph Hellwig:
"Two small hfsplus fixes:
- a one liner regression fix for large volume handling from Janne
Kalliomäki.
- a fixup for the boot image blessing feature to make it work with
the fake "hardlinks" in hfsplus from Matthew Garrett."
* branch 'hfsplus':
hfsplus: fix bless ioctl when used with hardlinks
hfsplus: fix overflow in sector calculations in hfsplus_submit_bio
HFS+ doesn't really implement hard links - instead, hardlinks are indicated
by a magic file type which refers to an indirect node in a hidden
directory. The spec indicates that stat() should return the inode number
of the indirect node, but it turns out that this doesn't satisfy the
firmware when it's looking for a bootloader - it wants the catalog ID of
the hardlink file instead. Fix up this case.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The variable io_size was unsigned int, which caused the wrong sector number
to be calculated after aligning it. This then caused mount to fail with big
volumes, as backup volume header information was searched from a
wrong sector.
Signed-off-by: Janne Kalliomäki <janne@tuxera.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Atom CPUs don't have a register to retrieve TjMax. Detection so far was
incomplete. Use the X86 model ID to improve it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Document the Atom series D2000 and N2000 (Cedar Trail) as being supported.
List and set TjMax for those series.
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: "R, Durgadoss" <durgadoss.r@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Document the new Atom series (Tunnel Creek and Medfield) as being
supported, and list TjMax for the Atom E600 series.
Also enable the Atom tjmax heuristic for these Atom CPU models.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reviewed-by: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: "R, Durgadoss" <durgadoss.r@intel.com>
Pull drm fixes from Dave Airlie:
"Radeon is most of the work, one regression, one BUG fix in the new
prime code, some fixes to init code to make streamout not lock up the
hardware, and just some code to enable users to test HDMI audio on
later hw (its off by default).
Intel adds edp edid caching for some strange Dell Vostros that black
screen on startup if keep reading their EDID, and a fix for a DP
regression.
Otherwise fix for via/sis and one to stop udl binding to multiple
non-video usb."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: cache the EDID for eDP panels
Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere"
drm/i915: eDP aux needs vdd
drm/i915: don't enumerate HDMID if an eDP panel is already active on the port
drm/radeon: add support for STRMOUT_BASE_UPDATE on 7xx
drm/radeon: add some additional 6xx/7xx/EG register init
drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)
drm sis: initialize object_idr
drm via: initialize object_idr
drm/radeon/prime: reserve/unreserve around pin
drm/radeon: fix regression in dynpm due to multi-ring rework
vga_switcheroo.h: fix pci_dev warning
drm/udl: only bind to the video devices on the hub.
For some reason one of the dev_err invocations is using a wrong
device so fix that.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: stable@vger.kernel.org
A bit larger set than usual, unfortunately -- I've been sitting on them
longer than I meant to so it's really more like 2 -rc pull requests in
one, volume-wise.
Nearly everything is fixes for fallout from the merge window, or other
fixes for bugs. The one exception is the highbank L2-enablement patch,
but it was contained enough that I picked it up anyway:
- i.MX fixes, mostly for clock and pinctrl changes
- OMAP fixes, mostly PM-related
- A patch to enable L2 on highbank
- A couple of fixes for PXA, Kirkwood, Versatile
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJP3WJDAAoJEIwa5zzehBx30kAP/11IlrLsylMgkjWNTCLaTv0X
03akBEy8NlfQrB4VL0gogo9UyJ6Y/NkcMftqdL217wBzWIOoeStj/gtW9CJutbd7
dD3Eldt1eojIcmPjANVNj0gHiT3FqBToRzRdONk2XK42D2D2IujA341uN4acAZP3
eeM5WhNAR+K+F2Yc8SrH93XjvnT6EwTlFnZ/fX4MV0Hee4wN0ajbGGl6lK8IXNN9
AIBjYY++fYSfnsbUr9KmAxcXwlAjmbl0VKCxWPhjSTsGFXVgf03JJdqejm+ZC8a8
i2fRmAYxaexyT72iIT5AGGEFQhSfAkDQJRKq3SBH21XXJKma4cxxsFNREkzJAx/Y
VFZ7W+o8WbykFi0Q4tCUfryrZWNbE+JZX1wsf1Jv5rPjLl0VJB8UuepRPAQjfApI
pNz64qo9xvBxXuI4gCFRP+xWmW88osN28Acv9ECi+cEeZ3H/nVWUHyAfjWaQyfqB
VbNvfHgbABjSRlrY51iIAJPp/zT9GiZwLigIGrqVk3iB/JHaDXCQ/yyELVOI7LtQ
sVCs9OvING/ZZtLKWdIEKBMxQVDTvn+DmHdnlD0xmGedKMw+OOfgeD74VLzwm5nK
OrPB1covGDEnp1yVP49xNocuSo9W/fqRnnHAIIuW0ZSdr24uHWOzf0/WYP3WQijB
sPz9l79iLSgKYh/r44s8
=x9VX
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A bit larger set than usual, unfortunately -- I've been sitting on
them longer than I meant to so it's really more like 2 -rc pull
requests in one, volume-wise.
Nearly everything is fixes for fallout from the merge window, or other
fixes for bugs. The one exception is the highbank L2-enablement
patch, but it was contained enough that I picked it up anyway:
- i.MX fixes, mostly for clock and pinctrl changes
- OMAP fixes, mostly PM-related
- A patch to enable L2 on highbank
- A couple of fixes for PXA, Kirkwood, Versatile"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (30 commits)
ARM: Kirkwood: Fix clk problems modular ethernet driver
arm: versatile: fix and enable PCI I/O space
ARM: highbank: Add smc calls to enable/disable the L2
ARM i.MX imx21ads: Fix overlapping static i/o mappings
ARM: imx6: exit coherency when shutting down a cpu
ARM: mx51: Add pinctrl_provide_dummies()
ARM: mx31: Add pinctrl_provide_dummies()
ARM: OMAP2+: Fix compile for CONFIG_TIDSPBRIDGE platform init code
ARM: OMAP3: Fix omap3_l3_block_irq warning when CONFIG_BUG is not set
ARM: OMAP: Fix MMC_OMAP build when only MMC_OMAP_HS is selected
OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
ARM: mmp: fix missing cascade_irq in irq handler
ARM: dts: update memory size on brownstone
ARM i.MX27 Visstrim M10: fix gpio handling.
ARM i.MX53: Fix PLL4 base address
ARM i.MX pllv2: make round_rate accurate
ARM i.MX pllv2: use standard register set unconditionally
ARM: OMAP: Fix lis3lv02d accelerometer to use gpio_to_irq
ARM: imx: only call l2x0_init if it's available
ARM: imx: only specify i2c device type once
...
When the ethernet driver was built as a module, it would lock the
machine when loaded. At boot the ethernet clks are unused, so get
turned off. Later, when the module is loaded, the probe function
would access the hardware before the clock was restarted, and the
machine would lock. It has also been determined that when the clk is
turned off, the interface forgets its MAC address, which for most
systems, is set by the boot loader.
When the machine setup file creates a platform device for the
interface, prepare and enable the clock for the interface. This will
ensure it is not turned off. However, if the setup file only
instantiates one platform device, the other will have its clk
disabled, thus maybe saving a little power.
Report-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
With commit 4d5fc58dbe (ARM: remove bunch of now unused
mach/io.h files), the I/O space setup was completely broken on
versatile. This patch fixes that and prepares for further
I/O space clean-up.
I/O space handling on the versatile platform is currently
broken in multiple ways. Most importantly, the ports do
not get mapped into the virtual address space at all.
Also, there is some amount of confusion between PCI I/O
space and other statically mapped MMIO registers in the
platform code:
* The __io_address() macro that is used to access the
platform register maps to the same __io macro that gets
used for I/O space.
* The IO_SPACE_LIMIT is set to a value that is much larger
than the total available space.
* The I/O resource of the PCI bus is set to the physical
address of the mapping, which is way outside of the
actual I/O space limit as well as the address range that
gets decoded by traditional PCI cards.
* No attempt is made to stay outside of the ISA port range
that some device drivers try access.
* No resource gets requested as a child of ioport_resource,
but an IORESOURCE_IO type mapping gets requested
as a child of iomem_resource.
This patch attempts to correct all of the above. This makes
it possible to use virtio-pci based virtual devices as well
as actual PCI cards including those with legacy ISA port
ranges like VGA.
Some of the issues seem to be duplicated on other platforms.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[rob: update to 3.5-rc2 and io.h cleanup related changes]
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Tested-by: Robert Schwebel <r.schwebel@pengutronix.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Pull btrfs compile warning fixes from Chris Mason.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Btrfs: cast devid to unsigned long long for printk %llu
Btrfs: init old_generation in get_old_root
Pull arch/tile update from Chris Metcalf:
"This one-line bug fix unbreaks glibc robust mutexes (among other
things no doubt), from code merged in during the 3.5 merge window but
which we had been running internally at Tilera for almost a year."
* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
tile: fix bug in get_user() for 4-byte values
- two fixes for s3c-fb by Jingoo Han
(including a fix for a potential division by zero)
- a couple of randconfig fixes by Arnd Bergmann
- a cleanup for bfin_adv7393fb by Emil Goode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
iQIcBAABAgAGBQJP3OVbAAoJECSVL5KnPj1P+BoP/jf20UvGevLHaKYLxjB6elWP
cutoJFgfPWWdJcu6qwk4thR3fAZkB9R1vorFEp0EP7m8EkB8poP7pdPK7xGzbLKT
iGhWUy4pENcleyPu0mXE2kqLfq5g3fnPc9M0aiIySwfGAgjop24duP9NYMBL5sfr
GHs7JcrcyqWWVDHQLK3gx7JpVzoQOlN44yy64Su2GR8hfLUiSHC35AVnmK8svkra
S5dTa9RJJwVFowF8/o5bUzFuuMctKc22CbXA2NkR+PUHHc0zAqaRo0XedTr02C8u
bM9w7RWxQ71ZprJJeaBJgUbDev0JO9QxX7kA6eN3MRTHimi2wz9n2jy95R+H3ITm
EXhCl6F2kf+xzOfl9Ta9lB4eUthj2O1yBHGArpc5iJOuWHip2ggW4SrEyjKLrOpn
7AyB+D9gbZppnms4z5kCPM0Q/i/flyMoEccuaV4D3AaWw1miA4leQUtfjL/SGavl
9t6N6Zo2OT/h+Z36GauFnH3ap4lXNGZo3I03sFGp7E4VC0MDA8UnqG70zzdzm7BM
CO/c34HVpNBS0MH6blsUn+64aftJampqVzlQ0uj++5R1fpDGBCo+p+WEkIx9GGqN
bhJbmXR0HPnHtNQtf/LCPv98V/OAnWpfC98EeewPAQ3MTAexpdS8JduuY3PjhdhD
TkLBbb6A5UCU90SV32AD
=0Zkc
-----END PGP SIGNATURE-----
Merge tag 'fbdev-fixes-for-3.5-1' of git://github.com/schandinat/linux-2.6
Pull fbdev fixes from Florian Tobias Schandinat:
- two fixes for s3c-fb by Jingoo Han (including a fix for a potential
division by zero)
- a couple of randconfig fixes by Arnd Bergmann
- a cleanup for bfin_adv7393fb by Emil Goode
* tag 'fbdev-fixes-for-3.5-1' of git://github.com/schandinat/linux-2.6:
video: s3c-fb: fix possible division by zero in s3c_fb_calc_pixclk
video: s3c-fb: clear SHADOWCON register when clearing hardware window registers
drivers/tosa: driver needs I2C and SPI to compile
drivers/savagefb: use mdelay instead of udelay
video/console: automatically select a font
video/ili9320: do not mark exported functions __devexit
drivers/video: use correct __devexit_p annotation
video: bfin_adv7393fb: Convert to kstrtouint_from_user
The definition of 32-bit values in the 64-bit tilegx architecture is that
they should be sign-extended regardless of whether they are considered
signed or unsigned by the compiler. Accordingly, we need to use an
"ld4s" rather than "ld4u" to load and sign-extend for get_user().
This fixes glibc bug 14238 (see http://sourceware.org/bugzilla),
introduced during the 3.5 merge window.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: cache the EDID for eDP panels
Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere"
drm/i915: eDP aux needs vdd
drm/i915: don't enumerate HDMID if an eDP panel is already active on the port
They aren't going anywhere, and probing on DDC can cause the panel to
blank briefly, so read them up front and cache them for later queries.
v2: fix potential NULL derefs in intel_dp_get_edid_modes and
intel_dp_get_edid (Jani)
copy full EDID length, including extension blocks (Takashi)
free EDID on teardown (Takashi)
v3: malloc a new EDID buffer that's big enough for the memcpy (Chris)
v4: change handling of NULL EDIDs, just preserve the NULL behavior
across detects and mode list fetches rather than trying to re-fetch
the EDID (Chris)
v5: be glad that Chris is around to remind me to hit C-x C-s before
committing.
References: https://bugs.freedesktop.org/show_bug.cgi?id=46856
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 092945e11c.
This commit prevents a DP screen from properly training the link.
Oddly enough it works, once the machine has been warm-booted with an
older kernel.
According to DP docs this _should_ have been the right precharge time.
Also, the commit that originally introduces this was just general snb
DP enabling and didn't mention any specific reason for this special
value. Whatever, trust the reporter that this makes things worse and
let's just revert it.
v2: Less spelling fail.
Cc: Adam Jackson <ajax@redhat.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: "Wouter M. Koolen" <W.M.Koolen-Wijkstra@cwi.nl>
Buglink: https://lkml.org/lkml/2012/6/14/301
Cc: stable@vger.kernel.org (only for 3.4)
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The new oui probe has been missing these.
This issue has been introduce in
commit 0d19832853
Author: Adam Jackson <ajax@redhat.com>
Date: Mon May 14 16:05:47 2012 -0400
drm/i915/dp: Probe branch/sink OUIs
v2: Do the eDP vdd dance of simply not probing the OUI on eDP panels
as suggested by Chris Wilson.
v3: Fix up the error path fail - I suck.
Cc: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
Tested-by: Yang Guang <guang.a.yang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This prevents the HDMI detect functions from poking at an eDP
connected panel, which can lead to trouble.
[danvet: Note that we have some other reports of DP vs. HDMI fighting,
but the general case is a much bigger fish to fry.]
References: https://bugs.freedesktop.org/show_bug.cgi?id=42278
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Required for streamout. Bump drm minor.
Marek v2: fix pkt->count check
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- SMX_SAR_CTL0 needs to be programmed correctly to prevent
problems with memory exports in certain cases.
- VC_ENHANCE needs to be initialized on 6xx/7xx.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Christian König <christian.koenig@amd.com>
Tested-by: Andre Heider <a.heider@gmail.com>
Tested-by: Zoltán Böszörményi <zboszor@pr.hu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The filed object_idr of struct drm_sis_private was introduced with
commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=6de8a748881f1cd9d795454da2b6db616d5ca3d7 .
The idr_init(&dev->object_name_idr) is called instead of
idr_init(&dev_priv->object_idr) by mistake, leaving object_idr
uninitialized. Correct this.
This patch was not tested because of lack of hardware.
Signed-off-by: Márton Németh <nm127@freemail.hu>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The field obejct_idr of struct drm_via_private was introduced with the
commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=77ee8f3825054f23b17e9c8f728f061defd86cdc .
In that patch idr_init(&dev->object_name_idr) was called instead of
idr_init(&dev_priv->object_idr) by mistake, leaving the dev_priv->object_idr
uninitialized. To be more exact, the object_idr buffer is filled with zeros
because of kzalloc(), but the dev_priv->object_idr.lock spinlock can cause
system freeze at lib/idr.c:move_to_free_list() when spin_lock_irqsave()
is called on this spinlock.
The patch was tested on Clevo D4J, model D410J laptop, on the following
hardware, without AGP kernel module loaded:
# lspci -s 01:00.0 -n
01:00.0 0300: 1106:3108 (rev 01)
# lspci -s 01:00.0 -v
01:00.0 VGA compatible controller: VIA Technologies, Inc. K8M800/K8N800/K8N800A [S3 UniChrome Pro] (rev 01) (prog-if 00 [VGA controller])
Subsystem: CLEVO/KAPOK Computer Device 4702
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
Memory at f0000000 (32-bit, prefetchable) [size=64M]
Memory at d1000000 (32-bit, non-prefetchable) [size=16M]
Expansion ROM at <unassigned> [disabled]
Capabilities: [60] Power Management version 2
Capabilities: [70] AGP version 3.0
Signed-off-by: Márton Németh <nm127@freemail.hu>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
I finally got to test this code a bit more and hit the ttm
no reserved assert, so add the reservations around the pinning.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Not all asics have all rings, so make sure the ring is ready
before attempting to check it in the dynpm work handler.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=43367
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix warnings on some architectures/configs (not on x86):
include/linux/vga_switcheroo.h:28:30: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
include/linux/vga_switcheroo.h:28:30: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Takashi Iwai <tiwai@suse.de>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Minchan Kim reports that when a system has many swap areas, and tmpfs
swaps out to the ninth or more, shmem_getpage_gfp()'s attempts to read
back the page cannot locate it, and the read fails with -ENOMEM.
Whoops. Yes, I blindly followed read_swap_header()'s pte_to_swp_entry(
swp_entry_to_pte()) technique for determining maximum usable swap
offset, without stopping to realize that that actually depends upon the
pte swap encoding shifting swap offset to the higher bits and truncating
it there. Whereas our radix_tree swap encoding leaves offset in the
lower bits: it's swap "type" (that is, index of swap area) that was
truncated.
Fix it by reducing the SWP_TYPE_SHIFT() in swapops.h, and removing the
broken radix_to_swp_entry(swp_to_radix_entry()) from read_swap_header().
This does not reduce the usable size of a swap area any further, it
leaves it as claimed when making the original commit: no change from 3.0
on x86_64, nor on i386 without PAE; but 3.0's 512GB is reduced to 128GB
per swapfile on i386 with PAE. It's not a change I would have risked
five years ago, but with x86_64 supported for ten years, I believe it's
appropriate now.
Hmm, and what if some architecture implements its swap pte with offset
encoded below type? That would equally break the maximum usable swap
offset check. Happily, they all follow the same tradition of encoding
offset above type, but I'll prepare a check on that for next.
Reported-and-Reviewed-and-Tested-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org [3.1, 3.2, 3.3, 3.4]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is a couple of minor fixes, one for a preempt warning in the mpt2sas
driver and one is a config failure with the new sd async domain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJP2fuGAAoJEDeqqVYsXL0Md88IAMw1nLZkg39TzEM4tAkkCa4C
o3e3xcmUdO1lqswmgUDaD95Z0H9MUBxwHWQGiAQ7fheuyXXyGOLINkBTx7wOGksk
JpsjEHNhVwW2rxFwZDLYxvtBjRy9E6wJPeuBQxQdU2gGVzjmk2bAV6mJnf+/wDkH
uqJKnrmVNU7x5drw1wP2z0i3zm8UZVlB+eW3J5ReZzfQlpBYWmFcwxrSTp8Q03ko
rx+rMNYlQO+5Cp0/UZxdIlTw4TTaU+F6bXC8jPzZ2zj0mUWtBxiF6rYZQlebNM5n
/byCuivfM9OMeWaiwk5ERIQ/1iOUF4L5apCNUIG2PFtS7RY4349luWpBoeYkaVY=
=eNSh
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is a couple of minor fixes, one for a preempt warning in the
mpt2sas driver and one is a config failure with the new sd async
domain."
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
[SCSI] Fix sd_probe_domain config problem
[SCSI] mpt2sas: Fix unsafe using smp_processor_id() in preemptible
