Lets not trick ourselves into thinking "drm_device" objects are not
ref-counted. That's just utterly stupid. We manage "drm_minor" objects on
each drm-device and each minor can have an unlimited number of open
handles. Each of these handles has the drm_minor (and thus the drm_device)
as private-data in the file-handle. Therefore, we may not destroy
"drm_device" until all these handles are closed.
It is *not* possible to reset all these pointers atomically and restrict
access to them, and this is *not* how this is done! Instead, we use
ref-counts to make sure the object is valid and not freed.
Note that we currently use "dev->open_count" for that, which is *exactly*
the same as a reference-count, just open coded. So this patch doesn't
change any semantics on DRM devices (well, this patch just introduces the
ref-count, anyway. Follow-up patches will replace open_count by it).
Also note that generic VFS revoke support could allow us to drop this
ref-count again. We could then just synchronously disable any fops->xy()
calls. However, this is not the case, yet, and no such patches are
in sight (and I seriously question the idea of dropping the ref-cnt
again).
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Use enum for DRM_MINOR_* constants to avoid hard-coding the IDs.
Furthermore, add a DRM_MINOR_CNT so we can perform range-checks in
follow-ups.
This changes the IDs of the minor-types by -1, but they're not used as
indices so this is fine.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The drm_open_helper() function is only used internally for drm_open() so
we can safely pass in the minor-object directly instead of the minor-id.
This way, we avoid the additional minor IDR lookup, which we already do
twice in drm_stub_open() and drm_open().
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These members are all managed by DRM-core, lets group them together so
they're not split across the whole device.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With dev->anon_inode we have a global address_space ready for operation
right from the beginning. Therefore, there is no need to do a delayed
setup with TTM. Instead, set dev_mapping during initialization in
ttm_bo_device_init() and remove any "if (dev_mapping)" conditions.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
DRM drivers share a common address_space across all character-devices of a
single DRM device. This allows simple buffer eviction and mapping-control.
However, DRM core currently waits for the first ->open() on any char-dev
to mark the underlying inode as backing inode of the device. This delayed
initialization causes ugly conditions all over the place:
if (dev->dev_mapping)
do_sth();
To avoid delayed initialization and to stop reusing the inode of the
char-dev, we allocate an anonymous inode for each DRM device and reset
filp->f_mapping to it on ->open().
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Our current DRM design uses a single address_space for all users of the
same DRM device. However, there is no way to create an anonymous
address_space without an underlying inode. Therefore, we wait for the
first ->open() callback on a registered char-dev and take-over the inode
of the char-dev. This worked well so far, but has several drawbacks:
- We screw with FS internals and rely on some non-obvious invariants like
inode->i_mapping being the same as inode->i_data for char-devs.
- We don't have any address_space prior to the first ->open() from
user-space. This leads to ugly fallback code and we cannot allocate
global objects early.
As pointed out by Al-Viro, fs/anon_inode.c is *not* supposed to be used by
drivers for anonymous inode-allocation. Therefore, this patch follows the
proposed alternative solution and adds a pseudo filesystem mount-point to
DRM. We can then allocate private inodes including a private address_space
for each DRM device at initialization time.
Note that we could use:
sysfs_get_inode(sysfs_mnt->mnt_sb, drm_device->dev->kobj.sd);
to get access to the underlying sysfs-inode of a "struct device" object.
However, most of this information is currently hidden and it's not clear
whether this address_space is suitable for driver access. Thus, unless
linux allows anonymous address_space objects or driver-core provides a
public inode per device, we're left with our own private internal mount
point.
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
There is no need to initialize this variable, so drop it. Otherwise, the
compiler won't warn if we use it unintialized.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Lets make sure some basic expressions are always true:
bpp != NULL
width != NULL
height != NULL
stride = bpp * width < 2^32
size = stride * height < 2^32
PAGE_ALIGN(size) < 2^32
At least the udl driver doesn't check for multiplication-overflows, so
lets just make sure it will never happen. These checks allow drivers to do
any 32bit math without having to test for mult-overflows themselves.
The two divisions might hurt performance a bit, but dumb_create() is only
used for scanout-buffers, so that should be fine. We could use 64bit math
to avoid the divisions, but that may be slow on 32bit machines.. Or maybe
there should just be a "safe_mult32()" helper, which currently doesn't
exist (I think?).
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
All drivers currently need to clean up the vma-node manually. There is no
fancy logic involved so lets just clean it up unconditionally. The
vma-manager correctly catches multiple calls so we are fine.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Probably a typo.. we obviously need "(bpp + 7) / 8" instead of
"(bpp + 1) / 8". Unlikely to be hit in any sane code, but lets be safe.
Use DIV_ROUND_UP() to avoid the problem entirely and make the core more
readable.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
We need to call dma_buf_end_cpu_access() in case a damage-request.
Unlikely, but might happen during device unplug.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
This is a set of six fixes. Two are instant crash/null deref types (storvsc
and isci). The two qla2xxx are initialisation problems that cause MSI-X
failures and card misdetection, the isci erroneous macro is actually illegal C
that's causing a miscompile with certain gcc versions and the be2iscsi bad if
expression is a static checker fix.
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJTJI/eAAoJEDeqqVYsXL0MSLkH/2uYBN9YkO6rkafxcIUYY0Ck
8+3xf7qdLVaEYoERkXQOncHg8r0BYWaUl0oi/K5nzq4chvMH3SW5L360SYRLT6Hs
0F2pFZ2bO192FPBSB2zxrkSDYmEtzBviUFbiWwVH2i1GJCGDMvI9TfDVbdnfF5Eh
YB5INjZQ0r5eS45uR5xo5VTotMOUd/3lfYCfcOLDB77SzkX280+OUXJOxRND4QtM
xKcWCahSR2ALzxy4+OUsSHsQNizjEufeDiTij1h9GJctbtPXgm4hRO04AEB2a0aQ
OBI5kKZobqh5DJgknBsASvYNDOaVOVlzML5Qs9m+ie1IEQBOtV6u1rQAONThy/8=
=1qQW
-----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 set of six fixes. Two are instant crash/null deref types
(storvsc and isci). The two qla2xxx are initialisation problems that
cause MSI-X failures and card misdetection, the isci erroneous macro
is actually illegal C that's causing a miscompile with certain gcc
versions and the be2iscsi bad if expression is a static checker fix"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
[SCSI] storvsc: NULL pointer dereference fix
[SCSI] qla2xxx: Poll during initialization for ISP25xx and ISP83xx
[SCSI] isci: correct erroneous for_each_isci_host macro
[SCSI] isci: fix reset timeout handling
[SCSI] be2iscsi: fix bad if expression
[SCSI] qla2xxx: Fix multiqueue MSI-X registration.
Since the last time I've looked more of this stuff sprouted up. Stomp
it down again.
Repeating the original justification for ripping this all out: There's
absolutely no need to deteach connectors before cleaning them up at
driver unload time. And since drm doesn't support hotplugging kms
objects at all it's positively dangerous to attempt this at runtime.
Luckily imx only detachs at driver cleanup time and hence we can
savely remove this.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull x86 fixes from Peter Anvin:
"Two x86 fixes: Suresh's eager FPU fix, and a fix to the NUMA quirk for
AMD northbridges.
This only includes Suresh's fix patch, not the "mostly a cleanup"
patch which had __init issues"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/amd/numa: Fix northbridge quirk to assign correct NUMA node
x86, fpu: Check tsk_used_math() in kernel_fpu_end() for eager FPU
- A recent ACPI resources handling fix overlooked the fact that it had
to update the ACPI PNP subsystem's resources parsing too and caused
confusing warning messages to be printed during system intialization
on some systems (with arguably buggy ACPI tables). Fix from Zhang Rui.
- Moving the early ACPI initialization before timekeeping_init() earlier
in this cycle broke fast TSC calibration on at least one system, so it
needs to be done later, but still before efi_enter_virtual_mode() to
allow the EFI initialization to refer to ACPI.
- A change related to code duplication reduction in the cpufreq core
inadvertently caused cpufreq intialization to fail for some CPUs
handled by intel_pstate by adding checks that may fail for that
driver, but aren't even necessary when it is used. The issue is
addressed by preventing those checks from run in the configurations
in which they aren't needed.
- If the Hardware Reduced ACPI flag is set in the ACPI tables, system
suspend, hibernation and ACPI power off will only work when special
sleep control and sleep status registeres are provided (their
addresses in the ACPI tables are not zero). If those registers are
not available, the features in question have no chances to work,
so they shouldn't even be regarded as supported. That helps with
power off in particular, because alternative power off methods may
be used then and they may actually work.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJTIyh1AAoJEILEb/54YlRxvw0P/RZIXtY5+c87JSRy+T1BBhN0
icpA7Qxu2unfckyR+anEIwrOFV7cvAMti7vJONWtSaFjp4sF8u2oEzs5T92DN74z
455sdieSZiTwDlvcbehSiaX6LFniK5OYLZ2RFGYh1D9uoxCSzfb9eugo7RNR+2iO
UMTMQG2RmI2bmjLHLTzotMRxmjRd8RSMVAwvyNULgDAZlrmfKwojqKyJUB7NThAm
kfAqVfzGs49+i0KF9hQrMeCEfNQF3Kj/HWMM78GHBNYu1uJVv+gXxMRUd8F9rGAO
d4Xy14lfLpjPeH/DCO+hqA9eu74gM5nwjM3DbUnsFtt+FUmyBPemnTHCksUfHEeH
wZlzuW0CndRqLijQa9tcFD6eeyh2tMztXCDu8r/UhpW1yGPkmW+SAU36SqqbmaGv
knU+2jte4i/p4etNyPlfNb9mX9G59QQLISkRRfD8hnMm79TGaVT1tVGQ8RCqEG8p
73kVhISZ2WLjO9dLG5q/3uzFvZdJNWPfI/9l570mz2M5+X7VeCMA/tDx5ofDz/hQ
5JWvqIzYDSSOGxTtB1xR9TuwtQblAnsiVlqUoEwfqZ8O8u+RdvP5ymgUREPvLQFN
jkCS1hdFleudZxqrn29MeEOJJg7DvFPyliMVvCxB2k1bg4HgJYWoZ0Hv0v0SKTd9
aCjbIOYxiLYV9clBSyLZ
=d2+L
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
"Three of these are regression fixes, for two recent regressions and
one introduced during the 3.13 cycle, and the fourth one is a working
version of the fix that had to be reverted last time.
Specifics:
- A recent ACPI resources handling fix overlooked the fact that it
had to update the ACPI PNP subsystem's resources parsing too and
caused confusing warning messages to be printed during system
intialization on some systems (with arguably buggy ACPI tables).
Fix from Zhang Rui.
- Moving the early ACPI initialization before timekeeping_init()
earlier in this cycle broke fast TSC calibration on at least one
system, so it needs to be done later, but still before
efi_enter_virtual_mode() to allow the EFI initialization to refer
to ACPI.
- A change related to code duplication reduction in the cpufreq core
inadvertently caused cpufreq intialization to fail for some CPUs
handled by intel_pstate by adding checks that may fail for that
driver, but aren't even necessary when it is used. The issue is
addressed by preventing those checks from run in the configurations
in which they aren't needed.
- If the Hardware Reduced ACPI flag is set in the ACPI tables, system
suspend, hibernation and ACPI power off will only work when special
sleep control and sleep status registeres are provided (their
addresses in the ACPI tables are not zero). If those registers are
not available, the features in question have no chances to work, so
they shouldn't even be regarded as supported. That helps with
power off in particular, because alternative power off methods may
be used then and they may actually work"
* tag 'pm+acpi-3.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states
ACPI / init: Invoke early ACPI initialization later
cpufreq: Skip current frequency initialization for ->setpolicy drivers
PNP / ACPI: proper handling of ACPI IO/Memory resource parsing failures
- fix corruption with >2TB fast device due to truncation bug
- fix access beyond end of origin device due to a partial block
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTIxzQAAoJEMUj8QotnQNa2AkIAMXpgGCvxAtuE072ARf2kwxx
qtTtdYms/r1ss8keOgACSDgcrn+NMjk4IP4+s54Iz7tViEgIF148gvqgbSeHwNzk
Vy49aIbVPj8GIqFxuFeS03DnBZ/loEWiLtiHG2BgKnNRy1NmLvGwLoYsrrn9RHWG
AAa4a2cCW/BcrYMJoZSYhlPEEPPvoqSpWTVJr1rjTkmQAAZSsOzsBdklkrEQtHzW
Sle8/OKp4tYwBmXml5XsfAPG+pNRkd7HizIRkJ0roP5iIWHLdnpGUvboKYdu1rVp
rxEl/nQeXzd8zDsUNvoRQs8CLmtEhBBj0h+L+P2Y3Aj7fNg67ismt25mplQWZsY=
=/XEY
-----END PGP SIGNATURE-----
Merge tag 'dm-3.14-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device-mapper fixes form Mike Snitzer:
"Two small fixes for the DM cache target:
- fix corruption with >2TB fast device due to truncation bug
- fix access beyond end of origin device due to a partial block"
* tag 'dm-3.14-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm cache: fix access beyond end of origin device
dm cache: fix truncation bug when copying a block to/from >2TB fast device
For systems with multiple servers and routed fabric, all
northbridges get assigned to the first server. Fix this by also
using the node reported from the PCI bus. For single-fabric
systems, the northbriges are on PCI bus 0 by definition, which
are on NUMA node 0 by definition, so this is invarient on most
systems.
Tested on fam10h and fam15h single and multi-fabric systems and
candidate for stable.
Signed-off-by: Daniel J Blueman <daniel@numascale.com>
Acked-by: Steffen Persvold <sp@numascale.com>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Pull drm fixes from Dave Airlie:
"Pretty minor set of fixes for radeon, ttm and vmwgfx. The ttm ones
are a regression and an oops seen on server chipsets"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/vmwgfx: Fix a surface reference corner-case in legacy emulation mode
drm/radeon/cik: properly set compute ring status on disable
drm/radeon/cik: stop the sdma engines in the enable() function
drm/radeon/cik: properly set sdma ring status on disable
drm/radeon: fix runpm disabling on non-PX harder
drm/ttm: don't oops if no invalidate_caches()
drm/ttm: Work around performance regression with VM_PFNMAP
Pull i2c Kconfig fix from Wolfram Sang.
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: Remove usage of orphaned symbol OF_I2C
Pull networking fixes from David Miller:
"I know this is a bit more than you want to see, and I've told the
wireless folks under no uncertain terms that they must severely scale
back the extent of the fixes they are submitting this late in the
game.
Anyways:
1) vmxnet3's netpoll doesn't perform the equivalent of an ISR, which
is the correct implementation, like it should. Instead it does
something like a NAPI poll operation. This leads to crashes.
From Neil Horman and Arnd Bergmann.
2) Segmentation of SKBs requires proper socket orphaning of the
fragments, otherwise we might access stale state released by the
release callbacks.
This is a 5 patch fix, but the initial patches are giving
variables and such significantly clearer names such that the
actual fix itself at the end looks trivial.
From Michael S. Tsirkin.
3) TCP control block release can deadlock if invoked from a timer on
an already "owned" socket. Fix from Eric Dumazet.
4) In the bridge multicast code, we must validate that the
destination address of general queries is the link local all-nodes
multicast address. From Linus Lüssing.
5) The x86 BPF JIT support for negative offsets puts the parameter
for the helper function call in the wrong register. Fix from
Alexei Starovoitov.
6) The descriptor type used for RTL_GIGA_MAC_VER_17 chips in the
r8169 driver is incorrect. Fix from Hayes Wang.
7) The xen-netback driver tests skb_shinfo(skb)->gso_type bits to see
if a packet is a GSO frame, but that's not the correct test. It
should use skb_is_gso(skb) instead. Fix from Wei Liu.
8) Negative msg->msg_namelen values should generate an error, from
Matthew Leach.
9) at86rf230 can deadlock because it takes the same lock from it's
ISR and it's hard_start_xmit method, without disabling interrupts
in the latter. Fix from Alexander Aring.
10) The FEC driver's restart doesn't perform operations in the correct
order, so promiscuous settings can get lost. Fix from Stefan
Wahren.
11) Fix SKB leak in SCTP cookie handling, from Daniel Borkmann.
12) Reference count and memory leak fixes in TIPC from Ying Xue and
Erik Hugne.
13) Forced eviction in inet_frag_evictor() must strictly make sure all
frags are deleted, otherwise module unload (f.e. 6lowpan) can
crash. Fix from Florian Westphal.
14) Remove assumptions in AF_UNIX's use of csum_partial() (which it
uses as a hash function), which breaks on PowerPC. From Anton
Blanchard.
The main gist of the issue is that csum_partial() is defined only
as a value that, once folded (f.e. via csum_fold()) produces a
correct 16-bit checksum. It is legitimate, therefore, for
csum_partial() to produce two different 32-bit values over the
same data if their respective alignments are different.
15) Fix endiannes bug in MAC address handling of ibmveth driver, also
from Anton Blanchard.
16) Error checks for ipv6 exthdrs offload registration are reversed,
from Anton Nayshtut.
17) Externally triggered ipv6 addrconf routes should count against the
garbage collection threshold. Fix from Sabrina Dubroca.
18) The PCI shutdown handler added to the bnx2 driver can wedge the
chip if it was not brought up earlier already, which in particular
causes the firmware to shut down the PHY. Fix from Michael Chan.
19) Adjust the sanity WARN_ON_ONCE() in qdisc_list_add() because as
currently coded it can and does trigger in legitimate situations.
From Eric Dumazet.
20) BNA driver fails to build on ARM because of a too large udelay()
call, fix from Ben Hutchings.
21) Fair-Queue qdisc holds locks during GFP_KERNEL allocations, fix
from Eric Dumazet.
22) The vlan passthrough ops added in the previous release causes a
regression in source MAC address setting of outgoing headers in
some circumstances. Fix from Peter Boström"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (70 commits)
ipv6: Avoid unnecessary temporary addresses being generated
eth: fec: Fix lost promiscuous mode after reconnecting cable
bonding: set correct vlan id for alb xmit path
at86rf230: fix lockdep splats
net/mlx4_en: Deregister multicast vxlan steering rules when going down
vmxnet3: fix building without CONFIG_PCI_MSI
MAINTAINERS: add networking selftests to NETWORKING
net: socket: error on a negative msg_namelen
MAINTAINERS: Add tools/net to NETWORKING [GENERAL]
packet: doc: Spelling s/than/that/
net/mlx4_core: Load the IB driver when the device supports IBoE
net/mlx4_en: Handle vxlan steering rules for mac address changes
net/mlx4_core: Fix wrong dump of the vxlan offloads device capability
xen-netback: use skb_is_gso in xenvif_start_xmit
r8169: fix the incorrect tx descriptor version
tools/net/Makefile: Define PACKAGE to fix build problems
x86: bpf_jit: support negative offsets
bridge: multicast: enable snooping on general queries only
bridge: multicast: add sanity check for general query destination
tcp: tcp_release_cb() should release socket ownership
...
The symbol is an orphan, don't depend on it anymore.
Signed-off-by: Richard Weinberger <richard@nod.at>
[wsa: enhanced commit message]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: 687b81d083 (i2c: move OF helpers into the core)
Cc: stable@kernel.org
If the HW Reduced ACPI mode bit is set in the FADT, ACPICA uses
the optional sleep control and sleep status registers for making
the system enter sleep states (including S5), so it is not possible
to use system sleep states or power it off using ACPI if the HW
Reduced ACPI mode bit is set and those registers are not available.
For this reason, add a new function, acpi_sleep_state_supported(),
checking if the HW Reduced ACPI mode bit is set and whether or not
system sleep states are usable in that case in addition to checking
the return value of acpi_get_sleep_type_data() and make the ACPI
sleep setup routines use that function to check the availability of
system sleep states.
Among other things, this prevents the kernel from attempting to
use ACPI for powering off HW Reduced ACPI systems without the sleep
control and sleep status registers, because ACPI power off doesn't
have a chance to work on them. That allows alternative power off
mechanisms that may actually work to be used on those systems. The
affected machines include Dell Venue 8 Pro, Asus T100TA, Haswell
Desktop SDP and Ivy Bridge EP Demo depot.
References: https://bugzilla.kernel.org/show_bug.cgi?id=70931
Reported-by: Adam Williamson <awilliam@redhat.com>
Tested-by: Aubrey Li <aubrey.li@linux.intel.com>
Cc: 3.4+ <stable@vger.kernel.org> # 3.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
tmp_prefered_lft is an offset to ifp->tstamp, not now. Therefore
age needs to be added to the condition.
Age calculation in ipv6_create_tempaddr is different from the one
in addrconf_verify and doesn't consider ADDRCONF_TIMER_FUZZ_MINUS.
This can cause age in ipv6_create_tempaddr to be less than the one
in addrconf_verify and therefore unnecessary temporary address to
be generated.
Use age calculation as in addrconf_modify to avoid this.
Signed-off-by: Heiner Kallweit <heiner.kallweit@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the Freescale fec is in promiscuous mode and network cable is
reconnected then the promiscuous mode get lost. The problem is caused
by a too soon call of set_multicast_list to re-enable promisc mode.
The FEC_R_CNTRL register changes are overwritten by fec_restart.
This patch fixes this by moving the call behind the init of FEC_R_CNTRL
register in fec_restart.
Successful tested on a i.MX28 board.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The commit d3ab3ffd1d
(bonding: use rlb_client_info->vlan_id instead of ->tag)
remove the rlb_client_info->tag, but occur some issues,
The vlan_get_tag() will return 0 for success and -EINVAL for
error, so the client_info->vlan_id always be set to 0 if the
vlan_get_tag return 0 for success, so the client_info would
never get a correct vlan id.
We should only set the vlan id to 0 when the vlan_get_tag return error.
Fixes: d3ab3ffd1d (bonding: use rlb_client_info->vlan_id instead of ->tag)
CC: Ding Tianhong <dingtianhong@huawei.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Acked-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When mlx4_en_stop_port() is called, we need to deregister also the
tunnel steering rules that relate to multicast.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We have two paths that try to reset the forcewake registers back to
known good values, with slightly different semantics and levels of
paranoia. Combine the two by passing a parameter to either restore the
forcewake status or to clear our bookkeeping, and raise the paranoia
level to max.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since commit d25f06ea46 "vmxnet3: fix netpoll race condition",
the vmxnet3 driver fails to build when CONFIG_PCI_MSI is disabled,
because it unconditionally references the vmxnet3_msix_rx()
function.
To fix this, use the same #ifdef in the caller that exists around
the function definition.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
Cc: "VMware, Inc." <pv-drivers@vmware.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: stable@vger.kernel.org
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add it to NETWORKING [GENERAL] to make sure patches for selftests
go to the netdev list as well.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It's been in there since forever, and no one cared. Doesn't put a too
good light onto our bug handling and QA efforts really ...
References: https://bugs.freedesktop.org/attachment.cgi?id=90970
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Standardized on "Returns:" Block.
- Sprinkle missing kerneldoc over all exported functions and all
ioctls.
- Add a stern warning that driver's really shouldn't use
drm_mode_group_init_legacy_group.
- Usual attempt at more consistency.
- Add warnings that drm_mode_object_get/put don't do refcounting,
despite what the names might lead to believe.
- Try to clarify the framebuffer setup/cleanup functions wrt driver
private framebuffers - I've fallen recently over this when reviewing
i915 fbdev patches.
- Align function parameters where the kerneldoc has been updated.
- Most of the drm_get_*_name functions aren't thread safe. Add stern
warnings where this is the case.
Since a lot of the functions in drm_crtc.c are boilerplate to handle
properties and create default sets of them it might be useful to
extract all that code into a new file drm_property.c. Especially since
properties will be used a lot more in the future.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Most of this is newly added kerneldoc for the hotplug and output
polling code. But I've also thrown in a bit lesser polish, most of it
is tuning down the shouting RETURN: headers.
Overview documentation for the output probing and mode setting support
code will be added in later patches.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No driver cares, and it should generally work. Add a big comment
when drivers can't use this for recompense.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- It yells.
- WARNing about incorrect locking is harder to ignore, so better
than kerneldoc.
- Since those have been written per-crtc locks were added ...
So remove them and replace them by appropriate WARNs.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rightfully no driver ever checked this - it can't fail.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oops. This is a regression from
commit 5d7a951537
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jan 4 22:31:20 2013 +0100
drm/doc: updates for new framebuffer lifetime rules
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It' unused and there's also not really any way to make it work with
the current code. So better rip it out.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Tune down yelling RETURNS.
- OCD align all the parameters the same.
- Add missing kerneldoc, which also means that we need to include the
kerneldoc from the drm_modes.h header now.
- Add missing Returns: sections.
- General polish and clarification - especially the kerneldoc for the
mode creation helpers seems to have been some good specimen of
copypasta gone wrong.
All actual code changes have all been extracted into prep patches
since there was simply too much to polish.
v2: More polish for the command line modeline functions.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Totally unused and actually redundant with maxX for display mode
validation. The fb helper otoh needs to check pitch limits,
but that is delegated into drivers instead.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It never fails and no one ever checked anyway.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's a neat FIXME asking whether this is really need. I'd
say really no.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I want to also include kerneldoc from the header (for static inline
functions and structs), but fishing the right pieces out of a giant
header is a real pain. So split things out.
Note that it's not a really clean header with sane include orders, but
given's drm historical knack for giant headers detangling this is a
major task.
v2: Also extract struct drm_cmdline_mode.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Makes more sense and gives better grouping in the DocBook function
reference sections. To make this possible we need to expose two
functions from drm_crtc.c though. To avoid further namespace pollution
in the system wide headers create a new internal header for such drm
internal symbols.
I expect that longer-term we'll add tons more, but since my goal here
is to polish the kerneldoc that's for another day.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's not really any value in stating that no locking is needed. And
even if the comment is useful, a check for the right mutex at the
beginning of the function is better since that can't be ingored as
easily as a bit of documentation.
Note that drm_mode_probed_add in drm_crtc.c is also changed, the next
patch will move this into drm_modes.c
v2: Don't add locking WARN_ONs where it is not strictly required (i.e.
the two functions to validate/prune mode lists).
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And clean it up so that there's no kerneldoc warnings. There's still a
lot to do with this one here.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
