- 28 1月, 2019 2 次提交
-
-
由 Philipp Zabel 提交于
Avoid declaring extern functions in c files. To make sure function definition and usage don't get out of sync, declare socfpga_reset_init in a common header. Suggested-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Acked-by: NDinh Nguyen <dinguyen@kernel.org>
-
由 Philipp Zabel 提交于
Avoid declaring extern functions in c files. To make sure function definition and usage don't get out of sync, declare sun6i_reset_init in a common header. Suggested-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
-
- 13 1月, 2019 1 次提交
-
-
由 John Hubbard 提交于
Commit 49e54187 ("ata: libahci_platform: comply to PHY framework") uses the PHY_MODE_SATA, but that enum had not yet been added. This caused a build failure for me, with today's linux.git. Also, there is a potentially conflicting (mis-named) PHY_MODE_SATA, hiding in the Marvell Berlin SATA PHY driver. Fix the build by: 1) Renaming Marvell's defined value to a more scoped name, in order to avoid any potential conflicts: PHY_BERLIN_MODE_SATA. 2) Adding the missing enum, which was going to be added anyway as part of [1]. [1] https://lkml.kernel.org/r/20190108163124.6409-3-miquel.raynal@bootlin.com Fixes: 49e54187 ("ata: libahci_platform: comply to PHY framework") Signed-off-by: NJohn Hubbard <jhubbard@nvidia.com> Acked-by: NJens Axboe <axboe@kernel.dk> Acked-by: NOlof Johansson <olof@lixom.net> Cc: Grzegorz Jaszczyk <jaz@semihalf.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 1月, 2019 6 次提交
-
-
由 Miquel Raynal 提交于
A feature has been added in the libahci driver: the possibility to set a new flag in hpriv->flags to let the core handle PHY suspend/resume automatically. Make use of this feature to make suspend to RAM work with SATA drives on A3700. Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Miquel Raynal 提交于
A3700 comphy initialization is done in the firmware (TF-A). Looking at the SATA PHY initialization routine, there is a comment about "vendor specific" registers. Two registers are mentioned. They are not initialized there in the firmware because they are AHCI related, while the firmware at this location does only PHY configuration. The solution to avoid doing such initialization is relying on U-Boot. While this work at boot time, U-Boot is definitely not going to run during a resume after suspending to RAM. Two possible solutions were considered: * Fixing the firmware. * Fixing the kernel driver. The first solution would take ages to propagate, while the second solution is easy to implement as the driver as been a little bit reworked to prepare for such platform configuration. Hence, this patch adds an Armada 3700 configuration function to set these two registers both at boot time (in the probe) and after a suspend (in the resume path). Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Miquel Raynal 提交于
At the beginning, only Armada 38x SoCs where supported by the ahci_mvebu.c driver. Commit 15d3ce7b ("ata: ahci_mvebu: add support for Armada 3700 variant") introduced Armada 3700 support. As opposed to Armada 38x SoCs, the 3700 variants do not have to configure mbus and the regret option. This patch took care of avoiding such configuration when not needed in the probe function, but failed to do the same in the resume path. While doing so looks harmless by experience, let's clean the driver logic and avoid doing this useless configuration with Armada 3700 SoCs. Because the logic is very similar between these two places, it has been decided to factorize this code and put it in a "Armada 38x configuration function". This function is part of a new (per-compatible) platform data structure, so that the addition of such configuration function for Armada 3700 will be eased. Fixes: 15d3ce7b ("ata: ahci_mvebu: add support for Armada 3700 variant") Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Miquel Raynal 提交于
For Armada-38x (32-bit) SoCs, PM platform support has been added since: commit 32f9494c ("ARM: mvebu: prepare pm-board.c for the introduction of Armada 38x support") commit 3cbd6a6c ("ARM: mvebu: Add standby support") For Armada 64-bit SoCs, like the A3700 also using this AHCI driver, PM platform support has always existed. There are even suspend/resume hooks in this driver since: commit d6ecf158 ("ata: ahci_mvebu: add suspend/resume support") Remove the stale comment at the end of this driver stating that all the above does not exist yet. Fixes: d6ecf158 ("ata: ahci_mvebu: add suspend/resume support") Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Miquel Raynal 提交于
Current implementation of the libahci does not take into account the new PHY framework. Correct the situation by adding a call to phy_set_mode() before phy_power_on(). PHYs should also be handled at suspend/resume time. For this, call ahci_platform_enable/disable_phys() at suspend/resume_host() time. These calls are guarded by a HFLAG (AHCI_HFLAG_SUSPEND_PHYS) that the user of the libahci driver must set manually in hpriv->flags at probe time. This is to avoid breaking users that have not been tested with this change. Reviewed-by: NHans de Goede <hdegoede@redhat.com> Suggested-by: NGrzegorz Jaszczyk <jaz@semihalf.com> Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Dmitry Safonov 提交于
Try to get reference for ldisc during tty_reopen(). If ldisc present, we don't need to do tty_ldisc_reinit() and lock the write side for line discipline semaphore. Effectively, it optimizes fast-path for tty_reopen(), but more importantly it won't interrupt ongoing IO on the tty as no ldisc change is needed. Fixes user-visible issue when tty_reopen() interrupted login process for user with a long password, observed and reported by Lukas. Fixes: c96cf923 ("tty: Don't block on IO when ldisc change is pending") Fixes: 83d817f4 ("tty: Hold tty_ldisc_lock() during tty_reopen()") Cc: Jiri Slaby <jslaby@suse.com> Reported-by: NLukas F. Hartmann <lukas@mntmn.com> Tested-by: NLukas F. Hartmann <lukas@mntmn.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NDmitry Safonov <dima@arista.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 11 1月, 2019 7 次提交
-
-
由 Jean-Philippe Brucker 提交于
When executed for a PCI_ROOT_COMPLEX type, iort_match_node_callback() expects the opaque pointer argument to be a PCI bus device. At the moment rc_dma_get_range() passes the PCI endpoint instead of the bus, and we've been lucky to have pci_domain_nr(ptr) return 0 instead of crashing. Pass the bus device to iort_scan_node(). Fixes: 5ac65e8c ("ACPI/IORT: Support address size limit for root complexes") Reported-by: NEric Auger <eric.auger@redhat.com> Signed-off-by: NJean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NEric Auger <eric.auger@redhat.com> Acked-by: NRobin Murphy <robin.murphy@arm.com> Cc: stable@vger.kernel.org Cc: Will Deacon <will.deacon@arm.com> Cc: Hanjun Guo <hanjun.guo@linaro.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Greg Kroah-Hartman 提交于
This reverts commit e6d09371. Turns out it is not needed at all, a fix for clang was made and accepted upstream in that project that makes this change unnecessary. So revert it. Reported-by: NNick Desaulniers <ndesaulniers@google.com> Cc: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Ilia Mirkin 提交于
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Takashi Iwai 提交于
When a fan is controlled via linear fallback without cstate, we shouldn't stop polling. Otherwise it won't be adjusted again and keeps running at an initial crazy pace. Fixes: 800efb4c ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the vbios") Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447Reported-by: NThomas Blume <thomas.blume@suse.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NMartin Peres <martin.peres@free.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Sowjanya Komatineni 提交于
Tegra194 supports maximum 64K Bytes transfer per packet. Tegra186 and prior supports maximum 4K Bytes transfer per packet. This patch fixes this payload difference between Tegra194 and prior Tegra chipsets using separate i2c_adapter_quirks. Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com> Acked-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Yi Zeng 提交于
If adapter->retries is set to a minus value from user space via ioctl, it will make __i2c_transfer and __i2c_smbus_xfer skip the calling to adapter->algo->master_xfer and adapter->algo->smbus_xfer that is registered by the underlying bus drivers, and return value 0 to all the callers. The bus driver will never be accessed anymore by all users, besides, the users may still get successful return value without any error or information log print out. If adapter->timeout is set to minus value from user space via ioctl, it will make the retrying loop in __i2c_transfer and __i2c_smbus_xfer always break after the the first try, due to the time_after always returns true. Signed-off-by: NYi Zeng <yizeng@asrmicro.com> [wsa: minor grammar updates to commit message] Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
- 10 1月, 2019 24 次提交
-
-
由 Daniele Ceraolo Spurio 提交于
commit 4a15c75c ("drm/i915: Introduce per-engine workarounds") refactored the workaround code to have functions per-engine, but didn't call any of them from logical_xcs_ring_init. Since we do have a non-RCS workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call intel_engine_init_workarounds for non-RCS engines. Note that whitelist is still RCS-only. v2: move the call to logical_ring_init (Chris) Fixes: 4a15c75c ("drm/i915: Introduce per-engine workarounds") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110013232.8972-2-daniele.ceraolospurio@intel.com (cherry picked from commit a60acb22) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
If we fail to pin the ggtt vma slot for the ppgtt page tables, we need to unwind the locals before reporting the error. Or else on subsequent attempts to bind the page tables into the ggtt, we will already believe that the vma has been pinned and continue on blithely. If something else should happen to be at that location, choas ensues. Fixes: a2bbf714 ("drm/i915/gtt: Only keep gen6 page directories pinned while active") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: <stable@vger.kernel.org> # v4.19+ Reviewed-by: NMatthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181222030623.21710-1-chris@chris-wilson.co.uk (cherry picked from commit d4de7535) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
Although commit fb6f0b64 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") applied cleanly after a 24 month hiatus, the code had moved on with new methods for peeking and fetching the captured gpu info. Make sure we catch all uses of the stashed error state and avoid dereferencing the error pointer. v2: Move error pointer determination into i915_gpu_capture_state v3: Restore early check to avoid capturing and then throwing away subsequent GPU error states. Fixes: fb6f0b64 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207110554.19897-1-chris@chris-wilson.co.uk (cherry picked from commit e6154e4c) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 José Roberto de Souza 提交于
i915 yet don't support PSR in Apple panels, so lets keep it disabled while we work on that. v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to DP_DPCD_QUIRK_NO_PSR (Ville) v3: Adding documentation to DP_DPCD_QUIRK_NO_PSR(Dhinakaran and Jani) Fixed typo in comment of the new quirk entry(Jani) Fixes: 598c6cfe (drm/i915/psr: Enable PSR1 on gen-9+ HW) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-1-jose.souza@intel.com (cherry picked from commit 7c5c641a) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Tetsuo Handa 提交于
We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc() failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc() succeeded. Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: Nsyzbot <syzbot+6ea337c427f5083ebdf2@syzkaller.appspotmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1547115571-21219-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
-
由 Vincent Guittot 提交于
Cast autosuspend_delay to u64 to make sure that the full computation of 'expires' or slack will be done in u64, even on 32bits arch. Otherwise, any delay greater than 2^31 nsec can overflow if signed 32bits is used when converting delay from msec to nsec. Fixes: 8234f673 (PM-runtime: Switch autosuspend over to using hrtimers) Reported-by: NTony Lindgren <tony@atomide.com> Tested-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NVincent Guittot <vincent.guittot@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Ladislav Michl 提交于
PM-runtime now uses the hrtimers infrastructure for autosuspend, however comments still reference 'jiffies'. Fixes: 8234f673 (PM-runtime: Switch autosuspend over to using hrtimers) Signed-off-by: NLadislav Michl <ladis@linux-mips.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Ilya Dryomov 提交于
There is a window between when RBD_DEV_FLAG_REMOVING is set and when the device is removed from rbd_dev_list. During this window, we set "already" and return 0. Returning 0 from write(2) can confuse userspace tools because 0 indicates that nothing was written. In particular, "rbd unmap" will retry the write multiple times a second: 10:28:05.463299 write(4, "0", 1) = 0 10:28:05.463509 write(4, "0", 1) = 0 10:28:05.463720 write(4, "0", 1) = 0 10:28:05.463942 write(4, "0", 1) = 0 10:28:05.464155 write(4, "0", 1) = 0 Cc: stable@vger.kernel.org Signed-off-by: NIlya Dryomov <idryomov@gmail.com> Tested-by: NDongsheng Yang <dongsheng.yang@easystack.cn>
-
由 Ivan Mironov 提交于
Strict requirement of pixclock to be zero breaks support of SDL 1.2 which contains hardcoded table of supported video modes with non-zero pixclock values[1]. To better understand which pixclock values are considered valid and how driver should handle these values, I briefly examined few existing fbdev drivers and documentation in Documentation/fb/. And it looks like there are no strict rules on that and actual behaviour varies: * some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c); * some treat (pixclock == 0) as invalid value which leads to -EINVAL (clps711x-fb.c); * some pass converted pixclock value to hardware (uvesafb.c); * some are trying to find nearest value from predefined table (vga16fb.c, video_gx.c). Given this, I believe that it should be safe to just ignore this value if changing is not supported. It seems that any portable fbdev application which was not written only for one specific device working under one specific kernel version should not rely on any particular behaviour of pixclock anyway. However, while enabling SDL1 applications to work out of the box when there is no /etc/fb.modes with valid settings, this change affects the video mode choosing logic in SDL. Depending on current screen resolution, contents of /etc/fb.modes and resolution requested by application, this may lead to user-visible difference (not always): image will be displayed in a right way, but it will be aligned to the left instead of center. There is no "right behaviour" here as well, as emulated fbdev, opposing to old fbdev drivers, simply ignores any requsts of video mode changes with resolutions smaller than current. The easiest way to reproduce this problem is to install sdl-sopwith[2], remove /etc/fb.modes file if it exists, and then try to run sopwith from console without X. At least in Fedora 29, sopwith may be simply installed from standard repositories. [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings [2] http://sdl-sopwith.sourceforge.net/Signed-off-by: NIvan Mironov <mironov.ivan@gmail.com> Cc: stable@vger.kernel.org Fixes: 79e53945 ("DRM: i915: add mode setting support") Fixes: 771fe6b9 ("drm/radeon: introduce kernel modesetting for radeon hardware") Fixes: 785b93ef ("drm/kms: move driver specific fb common code to helper functions (v2)") Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-3-mironov.ivan@gmail.com
-
由 Ivan Mironov 提交于
SDL 1.2 sets all fields related to the pixel format to zero in some cases[1]. Prior to commit db05c481 ("drm: fb-helper: Reject all pixel format changing requests"), there was an unintentional workaround for this that existed for more than a decade. First in device-specific DRM drivers, then here in drm_fb_helper.c. Previous code containing this workaround just ignores pixel format fields from userspace code. Not a good thing either, as this way, driver may silently use pixel format different from what client actually requested, and this in turn will lead to displaying garbage on the screen. I think that returning EINVAL to userspace in this particular case is the right option, so I decided to left code from problematic commit untouched instead of just reverting it entirely. Here is the steps required to reproduce this problem exactly: 1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL support. SDL should be compiled with fbdev support (which is on by default). 2) Create /etc/fb.modes with following contents (values seems not used, and just required to trigger problematic code in SDL): mode "test" geometry 1 1 1 1 1 timings 1 1 1 1 1 1 1 endmode 3) Create ~/.fceux/fceux.cfg with following contents: SDL.Hotkeys.Quit = 27 SDL.DoubleBuffering = 1 4) Ensure that screen resolution is at least 1280x960 (e.g. append "video=Virtual-1:1280x960-32" to the kernel cmdline for qemu/QXL). 5) Try to run fceux on VT with some ROM file[3]: # ./fceux color_test.nes [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, FB_SetVideoMode() [2] http://www.fceux.com [3] Example ROM: https://github.com/bokuweb/rustynes/blob/master/roms/color_test.nesReported-by: Nsaahriktu <mail@saahriktu.org> Suggested-by: Nsaahriktu <mail@saahriktu.org> Cc: stable@vger.kernel.org Fixes: db05c481 ("drm: fb-helper: Reject all pixel format changing requests") Signed-off-by: NIvan Mironov <mironov.ivan@gmail.com> [danvet: Delete misleading comment.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com
-
由 Jaegeuk Kim 提交于
If we don't drop caches used in old offset or block_size, we can get old data from new offset/block_size, which gives unexpected data to user. For example, Martijn found a loopback bug in the below scenario. 1) LOOP_SET_FD loads first two pages on loop file 2) LOOP_SET_STATUS64 changes the offset on the loop file 3) mount is failed due to the cached pages having wrong superblock Cc: Jens Axboe <axboe@kernel.dk> Cc: linux-block@vger.kernel.org Reported-by: NMartijn Coenen <maco@google.com> Reviewed-by: NBart Van Assche <bvanassche@acm.org> Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Anup Patel 提交于
In RISC-V, the M-mode runtime firmware provide SBI calls for debug prints. This patch adds earlycon support using RISC-V SBI console calls. To enable it, just pass "earlycon=sbi" in kernel parameters. Signed-off-by: NAnup Patel <anup@brainfault.org> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NPalmer Dabbelt <palmer@sifive.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
-
由 Christian König 提交于
We hit a problem with IOMMU with that. Disable until we have time to debug further. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jim Qu 提交于
effect asics: VEGA10 and VEGA12 Signed-off-by: NJim Qu <Jim.Qu@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Tao Zhou 提交于
Fix CPDMA hang in PRT mode for both VEGA10 and VEGA20 Signed-off-by: NTao Zhou <tao.zhou1@amd.com> Tested-by: NYukun.Li <yukun1.li@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Andrey Smirnov 提交于
ctrl->cntlid will already be initialized from id->cntlid for non-NVME_F_FABRICS controllers few lines below. For NVME_F_FABRICS controllers this field should already be initialized, otherwise the check if (ctrl->cntlid != le16_to_cpu(id->cntlid)) below will always be a no-op. Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: NKeith Busch <keith.busch@intel.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 James Dingwall 提交于
If a device provides an NQN it is expected to be globally unique. Unfortunately some firmware revisions for Intel 760p/Pro 7600p devices did not satisfy this requirement. In these circumstances if a system has >1 affected device then only one device is enabled. If this quirk is enabled then the device supplied subnqn is ignored and we fallback to generating one as if the field was empty. In this case we also suppress the version check so we don't print a warning when the quirk is enabled. Reviewed-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NJames Dingwall <james@dingwall.me.uk> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Keith Busch 提交于
We need to preserve the leading zeros in the vid and ssvid when generating a unique NQN. Truncating these may lead to naming collisions. Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
When nvme_init_identify() fails the ANA log buffer is deallocated but _not_ set to NULL. This can cause double free oops when this controller is deleted without ever being reconnected. Signed-off-by: NHannes Reinecke <hare@suse.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Sagi Grimberg 提交于
Even if user-space sent it to us, it got it wrong so lets help by disallowing it. Signed-off-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Sagi Grimberg 提交于
For sure we are a fabric driver. Signed-off-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Sagi Grimberg 提交于
We should never touch the opal device from the transport driver. Signed-off-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hongbo Yao 提交于
There is an out of bounds array access in nvme_cqe_peding(). When enable irq_thread for nvme interrupt, there is racing between the nvmeq->cq_head updating and reading. nvmeq->cq_head is updated in nvme_update_cq_head(), if nvmeq->cq_head equals nvmeq->q_depth and before its value set to zero, nvme_cqe_pending() uses its value as an array index, the index will be out of bounds. Signed-off-by: NHongbo Yao <yaohongbo@huawei.com> [hch: slight coding style update] Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Keith Busch 提交于
If the driver is unable to create a subset of IO queues for any reason, the read/write and polled queue sets will not match the actual allocated hardware contexts. This leaves gaps in the CPU affinity mappings and causes the following kernel panic after blk_mq_map_queue_type() returns a NULL hctx. BUG: unable to handle kernel NULL pointer dereference at 0000000000000198 #PF error: [normal kernel read fault] PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 64 PID: 1171 Comm: kworker/u259:1 Not tainted 4.20.0+ #241 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 Workqueue: nvme-wq nvme_scan_work [nvme_core] RIP: 0010:blk_mq_init_allocated_queue+0x2d9/0x440 RSP: 0018:ffffb1bf0abc3cd0 EFLAGS: 00010286 RAX: 000000000000001f RBX: ffff8ea744cf0718 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 000000000000007c RDI: ffffffff9109a820 RBP: ffff8ea7565f7008 R08: 000000000000001f R09: 000000000000003f R10: ffffb1bf0abc3c00 R11: 0000000000000000 R12: 000000000001d008 R13: ffff8ea7565f7008 R14: 000000000000003f R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8ea757200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000198 CR3: 0000000013058000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: blk_mq_init_queue+0x35/0x60 nvme_validate_ns+0xc6/0x7c0 [nvme_core] ? nvme_identify_ctrl.isra.56+0x7e/0xc0 [nvme_core] nvme_scan_work+0xc8/0x340 [nvme_core] ? __wake_up_common+0x6d/0x120 ? try_to_wake_up+0x55/0x410 process_one_work+0x1e9/0x3d0 worker_thread+0x2d/0x3d0 ? process_one_work+0x3d0/0x3d0 kthread+0x111/0x130 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 Modules linked in: nvme nvme_core serio_raw CR2: 0000000000000198 Fix by re-running the interrupt vector setup from scratch using a reduced count that may be successful until the created queues matches the irq affinity plus polling queue sets. Signed-off-by: NKeith Busch <keith.busch@intel.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Reviewed-by: NMing Lei <ming.lei@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-