Since commit a390d1f379cf ("phylib: convert state_queue work to
delayed_work"), the PHYLIB state machine was converted to use delayed
workqueues, yet some functions were still referencing the PHY library
timer in their comments, fix that and remove the now unused
linux/timer.h include.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski says:
====================
nfp: extend firmware request logic
We have been pondering for some time how to support loading different
application firmwares onto NFP. We want to support both users selecting
one of the firmware images provided by Netronome (which are optimized
for different use cases each) as well as firmware images created by
users themselves or other companies.
In the end we decided to go with the simplest solution - depending on
the right firmware image being placed in /lib/firmware. This vastly
simplifies driver logic and also doesn't require any new API.
Different NICs on one system may want to run different applications
therefore we first try to load firmware specific to the device (by
serial number of PCI slot) and if not present try the device model
based name we have been using so far.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
request_firmware() will fallback to user space helper and may cause
long delays when driver is loaded if udev doesn't correctly handle
FW requests. Since we never really made use of the user space
helper functionality switch to the simpler request_firmware_direct()
call. The side effect of this change is that no warning will be
printed when the FW image does not exists. To help users figure
out which FW file is missing print a info message when we request
each file.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We generally look up firmware by card type, but that doesn't allow
users who have more than one card of the same type in their system
to select firmware per adapter.
Unfortunately user space firmware helper seems fraught with
difficulties and to be on its way out. In particular support for
handling firmware uevents have been dropped from systemd and most
distributions don't enable the FW fallback by default any more.
To allow users selecting firmware for a particular device look up
firmware names by serial and pci_name(). Use the direct lookup to
disable generating uevents when enabled in Kconfig and not print
any warnings to logs if adapter-specific files are missing. Users
can place in /lib/firmware/netronome files named:
pci-${pci_name}.nffw
serial-${serial}.nffw
to target a specific card. E.g.:
pci-0000:04:00.0.nffw
pci-0000:82:00.0.nffw
serial-00-aa-bb-11-22-33-10-ff.nffw
We use the full serial number including the interface id, as it
appears in lspci output (bytes separated by '-').
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We use a hack to defer probe when firmware was not pre-loaded
or found on disk. This helps in case users forgot to include
firmware in initramfs, the driver will most likely get another
shot at probing after real root is mounted.
This is not for what EPROBE_DEFER is supposed to be used, and
when FW is completely missing every time new device is probed
NFP will reprobe spamming kernel logs.
Remove this hack, users will now have to make sure the right
firmware image is present in initramfs if nfp.ko is placed
there or built in.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The driver attempts to 'select MDIO_DEVICE', but the code
is actually a loadable module when PHYLIB=m:
drivers/phy/broadcom/phy-bcm-ns-usb3.o: In function `bcm_ns_usb3_mdiodev_phy_write':
phy-bcm-ns-usb3.c:(.text.bcm_ns_usb3_mdiodev_phy_write+0x28): undefined reference to `mdiobus_write'
drivers/phy/broadcom/phy-bcm-ns-usb3.o: In function `bcm_ns_usb3_module_exit':
phy-bcm-ns-usb3.c:(.exit.text+0x18): undefined reference to `mdio_driver_unregister'
drivers/phy/broadcom/phy-bcm-ns-usb3.o: In function `bcm_ns_usb3_module_init':
phy-bcm-ns-usb3.c:(.init.text+0x18): undefined reference to `mdio_driver_register'
phy-bcm-ns-usb3.c:(.init.text+0x38): undefined reference to `mdio_driver_unregister'
Using 'depends on MDIO_BUS' instead will avoid the link error.
Fixes: af850e14a7ae ("phy: bcm-ns-usb3: add MDIO driver using proper bus layer")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I still see build errors in randconfig builds and have had this
patch for a while to locally work around it:
drivers/built-in.o: In function `xgene_mdio_probe':
mux-core.c:(.text+0x352154): undefined reference to `of_mdiobus_register'
mux-core.c:(.text+0x352168): undefined reference to `mdiobus_free'
mux-core.c:(.text+0x3521c0): undefined reference to `mdiobus_alloc_size'
The idea is that CONFIG_MDIO_BUS now reflects whether the mdio_bus
code is built-in or a module, and other drivers that use the core
code can simply depend on that, instead of having a complex
dependency line.
Fixes: 90eff9096c01 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
i915 fixes for -rc3
Bit more than usual since we missed -rc2. 4x cc: stable, 2 gvt
patches, but all fairly minor stuff. Last minute rebase was to add a
few missing cc: stable, I did prep the pull this morning already and
made sure CI approves.
* tag 'drm-intel-fixes-2017-07-27' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915: Fix bad comparison in skl_compute_plane_wm.
drm/i915: Force CPU synchronisation even if userspace requests ASYNC
drm/i915: Only skip updating execobject.offset after error
drm/i915: Only mark the execobject as pinned on success
drm/i915: Remove assertion from raw __i915_vma_unpin()
drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence
drm/i915: Fix scaler init during CRTC HW state readout
drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'
drm/i915: Unbreak gpu reset vs. modeset locking
drm/i915: Fix cursor updates on some platforms
drm/i915: Fix user ptr check size in eb_relocate_vma()
drm/i915/gvt: Extend KBL platform support in GVT-g
drm/i915/gvt: Fix the vblank timer close issue after shutdown VMs in reverse
Core Changes:
- dp: A few fixes in drm_dp_downstream_debug() (Chris)
- rockchip: sanitize the Kconfig dependencies (fallout from EXTCON) (Arnd)
- host1x: Free the iommu domain when attach_device fails (Paul)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Kocialkowski <contact@paulk.fr>
* tag 'drm-misc-fixes-2017-07-27' of git://anongit.freedesktop.org/git/drm-misc:
gpu: host1x: Free the IOMMU domain when there is no device to attach
drm/rockchip: fix Kconfig dependencies
drm/dp: Don't trust drm_dp_downstream_id()
drm/dp: Fix read pointer for drm_dp_downsteam_debug()
- Add an ACPI module parameter to allow users to override the
new default behavior on some systems where the EC GPE is not
disabled during suspend-to-idle in case the EC on their systems
generates excessive wakeup events and they want to sacrifice
some functionality (like power button wakeups) for extra battery
life while suspended (Rafael Wysocki).
- Fix flushing of the outstanding EC work in the ACPI core
suspend-to-idle code (Rafael Wysocki).
- Add a missing include and fix a messed-up comment in the ACPI
NUMA code (Ross Zwisler).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJZellWAAoJEILEb/54YlRxSwoQAJkldP3toHoM6nqM+FSXL0U0
kAhQWgrxYxrpE1gZ/E/UkJc8+T3/tEkIMTlHynwb/eMPkxIVxNbhCpRlb0QpFgwR
d4RU4tZmI4hWpXZThq0AV3/Clok8AtqEkYH0O2Mc8kECEtOJFeQwPpRRNNf6Ahqx
1rRKGpTwClh43r7c+ncYqq2lYhTdXjMvnrrWBHI3ggRTTqCS3Nsmh09pGbTpJUJz
xJ40eMEcSVeSryvJRMNmqVrSUa59VXi0XoirZOPCRn5MriN9nQSnYf3eWSmimiOW
hqLqA5K1EtglRFDE+vYyRmeysd8Iuaf0Ic4YXlakzHfiUHGimcrEhOqh3NIWat1C
0DsnJcQ9Q7RsjWzu5/Rk7bMnSN+7HAxcc4jru+y9FOx/DdXG8aNNfmSYMSHJITVz
Vgrfd5ghnpMkvTZPGbjSZChG2U2zqm8hndjosH0+ioPwPT0lk1blphvWEC5SOjRR
Qx35m18RRTvVJVbiqY/P4g2PdL2wDCR/BHQR7hT12XOep3K+sRF536Vw/PXVCWWX
CBodBQUfrzHxgHoRkgrvZrk87a4X888dbmHAcvQuq3Mn1QA3ACYS6ymVL5UK/I+m
hgU7b6vWXSoOuP2hHjvWhtl0SoOYA3XYKrYZuOysQ7cd0FvRltEwF/BbP2Shf7vY
xfi9N8DE8BEymvP6cNhC
=m4S0
-----END PGP SIGNATURE-----
Merge tag 'acpi-4.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These are two fixups for the suspend-to-idle handling in the ACPI
subsystem after recent changes in that area and two simple fixes of
the ACPI NUMA code.
Specifics:
- Add an ACPI module parameter to allow users to override the new
default behavior on some systems where the EC GPE is not disabled
during suspend-to-idle in case the EC on their systems generates
excessive wakeup events and they want to sacrifice some
functionality (like power button wakeups) for extra battery life
while suspended (Rafael Wysocki).
- Fix flushing of the outstanding EC work in the ACPI core
suspend-to-idle code (Rafael Wysocki).
- Add a missing include and fix a messed-up comment in the ACPI NUMA
code (Ross Zwisler)"
* tag 'acpi-4.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: NUMA: Fix typo in the full name of SRAT
ACPI: NUMA: add missing include in acpi_numa.h
ACPI / PM / EC: Flush all EC work in acpi_freeze_sync()
ACPI / EC: Add parameter to force disable the GPE on suspend
* acpi-pm:
ACPI / PM / EC: Flush all EC work in acpi_freeze_sync()
ACPI / EC: Add parameter to force disable the GPE on suspend
* acpi-numa:
ACPI: NUMA: Fix typo in the full name of SRAT
ACPI: NUMA: add missing include in acpi_numa.h
ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same
as ddb_allocation >= blocks_per_line, so use the latter to simplify
this.
This fixes the following compiler warning:
drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a
boolean expression with an integer other than 0 or 1.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: d555cb5827d6 ("drm/i915/skl+: use linetime latency if ddb size is not available")
Cc: "Mahesh Kumar" <mahesh1.kumar@intel.com>
Reported-by: David Binderman <dcb314@hotmail.com>
Cc: David Binderman <dcb314@hotmail.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.13-rc1+
Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
(cherry picked from commit 54d20ed1fff23c7d2633f01fc788111bf9c51c5d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170717111355.4523-1-maarten.lankhorst@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The goal here was to minimise doing any thing or any check inside the
kernel that was not strictly required. For a userspace that assumes
complete control over the cache domains, the kernel is usually using
outdated information and may trigger clflushes where none were
required.
However, swapping is a situation where userspace has no knowledge of the
domain transfer, and will leave the object in the CPU cache. The kernel
must flush this out to the backing storage prior to use with the GPU. As
we use an asynchronous task tracked by an implicit fence for this, we
also need to cancel the ASYNC flag on the object so that the object will
wait for the clflush to complete before being executed. This also absolves
userspace of the responsibility imposed by commit 77ae9957897d ("drm/i915:
Enable userspace to opt-out of implicit fencing") that its needed to ensure
that the object was out of the CPU cache prior to use on the GPU.
Fixes: 77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101571
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-5-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 0f46daa1a273779a0b73d768a788ca3f04238f9c)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I was being overly paranoid in not updating the execobject.offset after
performing the fallback copy where we set reloc.presumed_offset to -1.
The thinking was to ensure that a subsequent NORELOC execbuf would be
forced to process the invalid relocations. However this is overkill so
long as we *only* update the execobject.offset following a successful
update of the relocation value witin the batch. If we have to repeat the
execbuf due to a later interruption, then we may skip the relocations on
the second pass (honouring NORELOC) since the execobject.offset match
the actual offsets (even though reloc.presumed_offset is garbage).
Subsequent calls to execbuf with NORELOC should themselves ensure that
the reloc.presumed_offset have been corrected in case of future
migration.
Reporting back the actual execobject.offset, even when
reloc.presumed_offset is garbage, ensures that reuse of those objects
use the latest information to avoid relocations.
Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101635
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-4-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 1f727d9e725a408ef58d159c20fb2e51818ff153)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After we detect a i915_vma pin overflow, we call __i915_vma_unpin to
cleanup. However, on an overflow the pin_count bitfield will be zero,
triggering an assertion, even though we the intention is to merely warn
and report the error back to the user (as historically the culprit has
be a leak in the display code).
Fixes: 20dfbde463c8 ("drm/i915: Wrap vma->pin_count accessors with small inline helpers")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 67fddd902b8e37b15a905c287ce4e40f52a564af)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The condition for setting the Loadgen Select bit of
PORT_TX_DW4 register during DDI Vswing Sequence should be
Bit rate <=6 GHz whereas the existing code checks only
Bit Rate < 6GHz. This patch fixes this condition.
While at it also remove the redundant paranthesis.
Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1500329122-32662-1-git-send-email-manasi.d.navare@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit a8e45a1c42d11597e975f3e5f2fe182f90cdaa7f)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even if the crtc is off. This fixes at least an initial YUV420 modeset
(added in a follow-up patchset by Shashank) when booting with the screen
off: after the initial HW readout and modeset which enables the scaler a
subsequent modeset will disable the scaler which isn't properly
allocated. This results in a funky HW state where the pipe scaler HW
registers can't be modified and the normally black screen is grey and
shifted to the right or jitters.
The problem was revealed by Shashank's YUV420 patchset and first
reported by Ville.
v2:
- In the stable tag also include versions which need backporting (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chandra Konduru <chandra.konduru@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: <stable@vger.kernel.org> # 4.2.x
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170720112820.26816-1-imre.deak@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 5fb9dadf336f3590c799e8cbde348215dccc2aa2)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Goto the right label in case of error, otherwise there is a leak.
This has been introduced by c5cf9a9147ff. In this patch a goto has not been
updated.
Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist from")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719223503.30580-1-christophe.jaillet@wanadoo.fr
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit a5ec7fe81a6ec38cb8b8a798d0552cbcadce7aa9)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Taking the modeset locks unconditionally isn't the greatest idea,
because atm that part is still broken and times out (and then atomic
keels over). And there's really no reason to do so, the old code
didn't do that either.
To make the patch a bit simpler let's also nuke 2 cases that are only
around for the old mmioflip paths. Atomic nonblocking workers will not
die (minus bugs) when a gpu reset happens.
And of course this doesn't fix any of the gpu reset vs. modeset
deadlock fun, but it at least stop modern CI machines from keeling
over all over the place for no reason at all.
And we still have the explicit testcases to run the fake gpu reset, so
coverage isn't that much worse.
v2: Split out additional changes on top, restrict this to purely reducing
the critical section of modeset locks.
v2: Review from Maarten
- update comments
- don't oops when state is NULL in intel_finish_reset, but try to at
least still drop locks properly. The hw is going to be toast anyway.
Fixes: 739748939974 ("drm/i915: Fix modeset handling during gpu reset, v5.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719125502.25696-3-daniel.vetter@ffwll.ch
(cherry picked from commit ce87ea15ebc60a9f8f156b2549f7b2cf7fe48d04)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull parisc fixes from Helge Deller:
- The majority of lines changed are due to regenerated defconfig files.
- The support for the Page Deallocation Table (PDT) which was merged in
the merge window for 4.13 contained a bug which crashes the kernel if
a bad page is reported by firmware. This is now fixed and the kernel
messages will show which memory slot holds the broken DIMM.
- Commit 3a166fc2d4ef ("kbuild: handle libs-y archives separately from
built-in.o archives") broke linking the parisc kernel due to
millicode symbols which can't be reached then any longer. This was
fixed by modifying the parisc vmlinux.lds linker script.
- If the stack checker panics on stack overflow, avoid recursive
panics.
- Some parisc machines can't physically power off and thus instead
start after some time to flood the console by presumably detected
soft lockups. Avoid this by disabling the lockup detectors before
entering the endless for-next loop.
- Dave Anglin provided fixes which prevents TLB speculation on flushed
pages on PA8800/PA9000 CPUs.
- Arvind Yadav sent a trivial patch to constify the attribute_group
structure in our firmware on-board-flash storage driver
(pdc_stable.c)
* 'parisc-4.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Extend disabled preemption in copy_user_page
parisc: Prevent TLB speculation on flushed pages on CPUs that only support equivalent aliases
parisc: Suspend lockup detectors before system halt
parisc: Show DIMM slot number which holds broken memory module
parisc: Add function to return DIMM slot of physical address
parisc: Fix crash when calling PDC_PAT_MEM PDT firmware function
parisc: regenerate defconfig files
parisc: pdc_stable: constify attribute_group structures.
parisc: Merge millicode routines via linker script
parisc: Disable further stack checks when panic occurs during stack check
Instead of fiddling with masking the event channels during suspend
and resume handling let do the irq subsystem do its job. It will do
the mask and unmask operations as needed.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Remove unnecessary static on local variables last_frontswap_pages and
tgt_frontswap_pages. Such variables are initialized before being used,
on every execution path throughout the function. The statics have no
benefit and, removing them reduce the code size.
This issue was detected using Coccinelle and the following semantic patch:
@bad exists@
position p;
identifier x;
type T;
@@
static T x@p;
...
x = <+...x...+>
@@
identifier x;
expression e;
type T;
position p != bad.p;
@@
-static
T x@p;
... when != x
when strict
?x = e;
You can see a significant difference in the code size after executing
the size command, before and after the code change:
before:
text data bss dec hex filename
5633 3452 384 9469 24fd drivers/xen/xen-selfballoon.o
after:
text data bss dec hex filename
5576 3308 256 9140 23b4 drivers/xen/xen-selfballoon.o
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
On systems that are not booted as a Xen domain, the xenfs driver prints
the following message during boot.
[ 3.460595] xenfs: not registering filesystem on non-xen platform
As the user chose not to boot a Xen domain, this message does not
provide useful information. Drop this message.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
This is a pretty boring pull request, containing a few HD-audio
quirks and ID updates as usual suspects, as well as a fix for a
regression of FM801 chip on ia64 (what a legacy combination!)
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEECxfAB4MH3rD5mfB6bDGAVD0pKaQFAll56twOHHRpd2FpQHN1
c2UuZGUACgkQbDGAVD0pKaQR9hAAoMI06lAQ1mIkGZ94ZAEUyQm3gOztGbLf7i17
Ek10iOOKawyp+ztzhLcoVWaznckpXoKSufGund/d9S2/krTx4pbg8oWidxJ9Ytl5
sBWUcRcgNdAhu6yoJToDQRCjVcejPT5CMUnLxN4vm1+5xtksOH845CWdhw7FhmsV
+yDhZnPdjaTZVmywjE+8N44F/JpmB2V+wLNpylRFur4YD18fHrqHxP55dxwO5LDD
gpbk4+2C7X5dLKviBn5QnUJsfZYf0hmTImiBGXblXeB2f8emKOBiFqw9T6pJNJOF
yCYRk/z7wdxWAOyqhzFn46MmLTGIFZKhKlX1eoN32uR0fwjnbY6XtOoL3mdIgs57
4F8M0xAEHuA4PP7J3gUqceczzBzFpmlNdajPDTRPK5onMCSKc+g2yz28MekwBB4u
Cavk5kZPous8QceAK7BukH1j8adEo9VPXa2ELV90aNx+jgQTi4Yy4dQ4LTzv97iV
D1yJXfLPtwoYzDw6FxeYJAr25sACJ22crXImCJktMjWftpT8ZUYYVy9ROvDVxrl5
VlfJ9XtoMvDT9D/9OcOrpa8BFWwsN75exwD1JxUiOyq2FpGHYg8aSl1GVHVlJSNE
ba+q52lTFzfmxKulPzfFYa0uhrrxsUNZpv5VZUBRXEHoaIlBzE8oGkz3yYEI0O5G
BjKoucY=
=y0Ak
-----END PGP SIGNATURE-----
Merge tag 'sound-4.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This is a pretty boring pull request, containing a few HD-audio quirks
and ID updates as usual suspects, as well as a fix for a regression of
FM801 chip on ia64 (what a legacy combination!)"
* tag 'sound-4.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Add mute led support for HP ProBook 440 G4
ALSA: hda/realtek - No loopback on ALC225/ALC295 codec
ALSA: hda/realtek - Update headset mode for ALC225
ALSA: fm801: Initialize chip after IRQ handler is registered
ALSA: hda/realtek - Update headset mode for ALC298
ALSA: hda - Add missing NVIDIA GPU codec IDs to patch table
Pull ARM fixes from Russell King:
"Two areas addressed by these fixes:
- Fixes from Dave Martin for the signal frames that were broken with
certain configurations. No one noticed until recently.
- More kexec fixes to ensure that the crashkernel region is correctly
allocated, and a fix for the location of the device tree when
several kexec kernels are loaded"
* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
ARM: 8687/1: signal: Fix unparseable iwmmxt_sigframe in uc_regspace[]
ARM: 8686/1: iwmmxt: Add missing __user annotations to sigframe accessors
ARM: kexec: fix failure to boot crash kernel
ARM: kexec: avoid allocating crashkernel region outside lowmem
posix_fallocate() will allocate space in an NFS file by considering
the last byte of every 4K block. If it is before EOF, it will read
the byte and if it is zero, a zero is written out. If it is after EOF,
the zero is unconditionally written.
For the blocks beyond EOF, if NFS believes its cache is valid, it will
expand these writes to write full pages, and then will merge the pages.
This results if (typically) 1MB writes. If NFS believes its cache is
not valid (particularly if NFS_INO_INVALID_DATA or
NFS_INO_REVAL_PAGECACHE are set - see nfs_write_pageuptodate()), it will
send the individual 1-byte writes. This results in (typically) 256 times
as many RPC requests, and can be substantially slower.
Currently nfs_revalidate_mapping() is only used when reading a file or
mmapping a file, as these are times when the content needs to be
up-to-date. Writes don't generally need the cache to be up-to-date, but
writes beyond EOF can benefit, particularly in the posix_fallocate()
case.
So this patch calls nfs_revalidate_mapping() when writing beyond EOF -
i.e. when there is a gap between the end of the file and the start of
the write. If the cache is thought to be out of date (as happens after
taking a file lock), this will cause a GETATTR, and the two flags
mentioned above will be cleared. With this, posix_fallocate() on a
newly locked file does not generate excessive tiny writes.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Prior to commit ca0daa277aca ("NFS: Cache aggressively when file is open
for writing"), NFS would revalidate, or invalidate, the file size when
taking a lock. Since that commit it only invalidates the file content.
If the file size is changed on the server while wait for the lock, the
client will have an incorrect understanding of the file size and could
corrupt data. This particularly happens when writing beyond the
(supposed) end of file and can be easily be demonstrated with
posix_fallocate().
If an application opens an empty file, waits for a write lock, and then
calls posix_fallocate(), glibc will determine that the underlying
filesystem doesn't support fallocate (assuming version 4.1 or earlier)
and will write out a '0' byte at the end of each 4K page in the region
being fallocated that is after the end of the file.
NFS will (usually) detect that these writes are beyond EOF and will
expand them to cover the whole page, and then will merge the pages.
Consequently, NFS will write out large blocks of zeroes beyond where it
thought EOF was. If EOF had moved, the pre-existing part of the file
will be over-written. Locking should have protected against this,
but it doesn't.
This patch restores the use of nfs_zap_caches() which invalidated the
cached attributes. When posix_fallocate() asks for the file size, the
request will go to the server and get a correct answer.
cc: stable@vger.kernel.org (v4.8+)
Fixes: ca0daa277aca ("NFS: Cache aggressively when file is open for writing")
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
When there is no device to attach to the IOMMU domain, as may be the
case when the device-tree does not contain the proper iommu node, it is
best to keep going without IOMMU support rather than failing.
This allows the driver to probe and function instead of taking down
all of the tegra drm driver, leading to missing display support.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170710193305.5987-1-contact@paulk.fr
dwmmc host driver already deprecate it in the driver
but didn't modify the documentation to reflect the fact.
This patch deprecates it and clean up num-slots from the
examples of all variant host drivers.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Fixes: d30a8f7bdf64 ("mmc: dw_mmc: deprecated the "num-slots" property")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Change to print the information about when the deprecated "num-slots" DT
binding is being used, as to avoid confusion when browsing the log:
dwmmc_rockchip fe320000.dwmmc: 'num-slots' was deprecated.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Fixes: d30a8f7bdf64 ("mmc: dw_mmc: deprecated the "num-slots" property")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When adding ethtool steering rule with action DISCARD we wrongly
pass a NULL dest with dest_num 1 to mlx5_add_flow_rules().
What this error seems to have caused is sending VPORT 0
(MLX5_FLOW_DESTINATION_TYPE_VPORT) as the fte dest instead of no dests.
We have fte action correctly set to DROP so it might been ignored
anyways.
To reproduce use:
# sudo ethtool --config-nfc <dev> flow-type ether \
dst aa:bb:cc:dd:ee:ff action -1
Fixes: 74491de93712 ("net/mlx5: Add multi dest support")
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
This is done in order to ensure that work will not run after the cleanup.
Fixes: ef9814deafd0 ('net/mlx5e: Add HW timestamping (TS) support')
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
The overflow_period is calculated in seconds. In order to use it
for delayed work scheduling translation to jiffies is needed.
Fixes: ef9814deafd0 ('net/mlx5e: Add HW timestamping (TS) support')
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Add the missing option to enable the PTP_CLK_PPS function.
In this case pin should be configured as 1PPS IN first and
then it will be connected to PPS mechanism.
Events will be reported as PTP_CLOCK_PPSUSR events to relevant sysfs.
Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support')
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
In order to fix the drift in 1PPS out need to adjust the next pulse.
On each 1PPS out falling edge driver gets the event, then the event
handler adjusts the next pulse starting time.
Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support')
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Need to disable the MTPPS and unsubscribe from the pulse events
when user disables the 1PPS functionality.
Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support')
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
In order to mark relevant fields while setting the MTPPS register
add field select. Otherwise it can cause a misconfiguration in
firmware.
Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support')
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
outer_header_zero() routine checks if the outer_headers match of a
flow-table entry are all zero.
This function uses the size of whole fte_match_param, instead of just
the outer_headers member, causing failure to detect all-zeros if
any other members of the fte_match_param are non-zero.
Use the correct size for zero check.
Fixes: 6dc6071cfcde ("net/mlx5e: Add ethtool flow steering support")
Signed-off-by: Ilan Tayari <ilant@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
On interface remove, the clean-up was done incorrectly causing
an error in the log:
"SET_FLOW_TABLE_ROOT(0x92f) op_mod(0x0) failed...syndrome (0x7e9f14)"
This was caused by the following flow:
-ndo_uninit:
Move QP state to RST (this disconnects the QP from FT),
the QP cannot be attached to any FT unless it is in RTS.
-mlx5_rdma_netdev_free:
cleanup_rx: Destroy FT
cleanup_tx: Destroy QP and remove QPN from FT
This caused a problem when destroying current FT we tried to
re-attach the QP to the next FT which is not needed.
The correct flow is:
-mlx5_rdma_netdev_free:
cleanup_rx: remove QPN from FT & Destroy FT
cleanup_tx: Destroy QP
Fixes: 508541146af1 ("net/mlx5: Use underlay QPN from the root name space")
Signed-off-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
When driver fail to allocate an entry to send command to FW, it must
notify the calling function and release the memory allocated for
this command.
Fixes: e126ba97dba9e ('mlx5: Add driver for Mellanox Connect-IB adapters')
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
Cc: kernel-team@fb.com
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Completion on timeout should not free the driver command entry structure
as it will need to access it again once real completion event from FW
will occur.
Fixes: 73dd3a4839c1 ('net/mlx5: Avoid using pending command interface slots')
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
Cc: kernel-team@fb.com
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
The tx_enabled lag event field is used to determine whether a slave is
active.
Current logic uses this value only if the mode is active-backup.
However, LACP mode, although considered a load balancing mode, can mark
a slave as inactive in certain situations (e.g., LACP timeout).
This fix takes the tx_enabled value into account when remapping, with
no respect to the LAG mode (this should not affect the behavior in XOR
mode, since in this mode both slaves are marked as active).
Fixes: 7907f23adc18 (net/mlx5: Implement RoCE LAG feature)
Signed-off-by: Aviv Heller <avivh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Upon sriov enable, eswitch is always enabled.
Currently, if enable hca failed over all VFs, we would skip eswitch
disable as part of sriov disable, which will lead to resources leak.
Fix it by disabling eswitch if it was enabled (use indication from
eswitch mode).
Fixes: 6b6adee3dad2 ('net/mlx5: SRIOV core code refactoring')
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Noa Osherovich <noaos@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
That commit was part of the changes moving x86 to the generic CPU hotplug
interrupt migration code. The force flag was required on x86 before the
hierarchical irqdomain rework, but invoking set_affinity() with force=true
stayed and had no side effects.
At some point in the past, the force flag got repurposed to support the
exynos timer interrupt affinity setting to a not yet online CPU, so the
interrupt controller callback does not verify the supplied affinity mask
against cpu_online_mask.
Setting the flag in the CPU hotplug code causes the cpu online masking to
be blocked on these irq controllers and results in potentially affining an
interrupt to the CPU which is unplugged, i.e. instead of moving it away,
it's just reassigned to it.
As the force flags is not longer needed on x86, it's safe to revert that
patch so the ARM irqchips which use the force flag work again.
Add comments to that effect, so this won't happen again.
Note: The online mask handling should be done in the generic code and the
force flag and the masking in the irq chips removed all together, but
that's not a change possible for 4.13.
Fixes: 77f85e66aa8b ("genirq/cpuhotplug: Set force affinity flag on hotplug migration")
Reported-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: LAK <linux-arm-kernel@lists.infradead.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1707271217590.3109@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Since the PMU register interface is banked per CPU, CPU PMU interrrupts
cannot be handled by a CPU other than the one with the PMU asserting the
interrupt. This means that migrating PMU SPIs, as we do during a CPU
hotplug operation doesn't make any sense and can lead to the IRQ being
disabled entirely if we route a spurious IRQ to the new affinity target.
This has been observed in practice on AMD Seattle, where CPUs on the
non-boot cluster appear to take a spurious PMU IRQ when coming online,
which is routed to CPU0 where it cannot be handled.
This patch passes IRQF_PERCPU for PMU SPIs and forcefully sets their
affinity prior to requesting them, ensuring that they cannot
be migrated during hotplug events. This interacts badly with the DB8500
erratum workaround that ping-pongs the interrupt affinity from the handler,
so we avoid passing IRQF_PERCPU in that case by allowing the IRQ flags
to be overridden in the platdata.
Fixes: 3cf7ee98b848 ("drivers/perf: arm_pmu: move irq request/free into probe")
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Due to a bugfix in wireless tree and the commit mentioned below a merge
was needed which went haywire. So the submitted change resulted in the
function brcmf_sdiod_sgtable_alloc() being called twice during the probe
thus leaking the memory of the first call.
Cc: stable@vger.kernel.org # 4.6.x
Fixes: 4d7928959832 ("brcmfmac: switch to new platform data")
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
