summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-05usb: typec: tipd: Switch CD321X power state to S0Sven Peter2-0/+43
The Apple CD321x comes up in a low-power state after boot. Usually, the bootloader will already power it up to S0 but let's do it here as well in case that didn't happen. Suggested-by: Stan Skowronek <stan@corellium.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20210928155502.71372-6-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: tipd: Add support for Apple CD321XSven Peter3-1/+91
Apple CD321x chips are a variant of the TI TPS 6598x chips. The major differences are the changed interrupt numbers and the concurrent connection to the SMC which we must not disturb. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20210928155502.71372-5-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: tipd: Add short-circuit for no irqsSven Peter1-1/+6
If no interrupts are set in IntEventX directly skip to the end of the interrupt handler and return IRQ_NONE instead of IRQ_HANDLED. This possibly allows to detect spurious interrupts if the i2c bus is fast enough. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20210928155502.71372-4-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: tipd: Split interrupt handlerSven Peter1-31/+65
Split the handlers for the individual interrupts into their own functions to prepare for adding a second interrupt handler for the Apple CD321x chips Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20210928155502.71372-3-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05dt-bindings: usb: tps6598x: Add Apple CD321x compatibleSven Peter1-0/+4
A variant of the TI TPS 6598x Type-C Port Switch and Power Delivery controller known as Apple CD321x is present on boards with Apple SoCs such as the M1. Add its compatible to the device tree binding. Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20210928155502.71372-2-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: ucsi: Better fix for missing unplug events issueHeikki Krogerus2-147/+45
The commit 217504a05532 ("usb: typec: ucsi: Work around PPM losing change information") had solved this issue previously, but in a really complex manner. The core issue is that on some platforms the EC firmware does not interrupt the driver on unplug event in some cases, mainly when the cable is unplugged immediately after the plug-in. From now on handling that problem by simply re-checking new connections. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210920142419.54493-8-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: ucsi: Read the PDOs in separate workHeikki Krogerus1-13/+17
Polling also the PDOs, just like the alt modes. After this ucsi_handle_connector_change() doesn't execute any commands. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210920142419.54493-7-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: ucsi: Check the partner alt modes always if there is PD contractHeikki Krogerus1-5/+9
UCSI does not tell the driver explicitly when the firmware (PPM in UCSI lingo) has actually detected the partner alternate modes, there is no specific change event for that. That's why they have to be checked with any notification that informs that PD contract with that partner has been achieved. Previously the alternate modes were checked always when the firmware (PPM) informed that something with the partner had changed, but on some platforms the EC firmware does not generate separate events for generic partner changes at all. On those platforms the EC firmware notifies the driver only about connections, or separately about the PD contract if it was not achieved soon enough after the initial connection event. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210920142419.54493-6-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: ucsi: acpi: Reduce the command completion timeoutHeikki Krogerus1-1/+1
The huge delay was there to workaround a problem where the firmware did not report that it was busy with the alternate mode commands. Now that the alternate modes are polled, the delay can be dropped. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210920142419.54493-5-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checkingHeikki Krogerus2-19/+101
The "poll worker" that is introduced here is first used for checking partner alternate modes, but it can later be used for any partner task that requires a separate job to be scheduled to the connector specific workqueues. The mechanism allows the partner device specific tasks to be polling tasks and also delayed tasks if necessary. By polling the partner alternate modes with this mechanism the long command completion timeout value can be reduced back to normal. The long command completion timeout was only used to work around a problem on some platforms where the EC firmware (PPM) didn't return BUSY even when it should with the alt mode commands. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210920142419.54493-4-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: ucsi: Don't stop alt mode registration on busy conditionHeikki Krogerus1-0/+2
If the PPM says it's busy, we can now simply try again. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210920142419.54493-3-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: ucsi: Always cancel the command if PPM reports BUSY conditionHeikki Krogerus1-1/+3
This makes it possible to execute next command immediately after the busy condition. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210920142419.54493-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: typec: tcpci: Fix spelling mistake "resolbed" -> "resolved"Xu Yang1-1/+1
There is a spelling mistake in a comment. Fix it. Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20210922060152.2892027-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05usb: misc: ehset: Workaround for "special" hubsRazvan Heghedus1-16/+65
The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. But there are some "special" hubs, which requires to disable the port power before sending the test command. Because the USB spec mention that the port should be suspended, also do this step before sending the test command. This could rise the problem with other hubs which are not compliant with the spec and the test command will not work if the port is suspend. If such hubs are found, a similar workaround like the disable part could be implemented to skip the suspend port command. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20210915121615.3790-1-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05afs: Fix afs_launder_page() to set correct start file positionDavid Howells1-2/+1
Fix afs_launder_page() to set the starting position of the StoreData RPC at the offset into the page at which the modified data starts instead of at the beginning of the page (the iov_iter is correctly offset). The offset got lost during the conversion to passing an iov_iter into afs_store_data(). Changes: ver #2: - Use page_offset() rather than manually calculating it[1]. Fixes: bd80d8a80e12 ("afs: Use ITER_XARRAY for writing") Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeffrey Altman <jaltman@auristor.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/YST/0e92OdSH0zjg@casper.infradead.org/ [1] Link: https://lore.kernel.org/r/162880783179.3421678.7795105718190440134.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/162937512409.1449272.18441473411207824084.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/162981148752.1901565.3663780601682206026.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/163005741670.2472992.2073548908229887941.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/163221839087.3143591.14278359695763025231.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/163292980654.4004896.7134735179887998551.stgit@warthog.procyon.org.uk/ # v2
2021-10-05netfs: Fix READ/WRITE confusion when calling iov_iter_xarray()David Howells1-1/+1
Fix netfs_clear_unread() to pass READ to iov_iter_xarray() instead of WRITE (the flag is about the operation accessing the buffer, not what sort of access it is doing to the buffer). Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers") Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: linux-cachefs@redhat.com cc: linux-afs@lists.infradead.org cc: ceph-devel@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: linux-nfs@vger.kernel.org cc: v9fs-developer@lists.sourceforge.net cc: linux-fsdevel@vger.kernel.org cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/162729351325.813557.9242842205308443901.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/162886603464.3940407.3790841170414793899.stgit@warthog.procyon.org.uk Link: https://lore.kernel.org/r/163239074602.1243337.14154704004485867017.stgit@warthog.procyon.org.uk
2021-10-05cachefiles: Fix oops with cachefiles_cull() due to NULL objectDave Wysochanski1-2/+2
When cachefiles_cull() calls cachefiles_bury_object(), it passes a NULL object. When this occurs, either trace_cachefiles_unlink() or trace_cachefiles_rename() may oops due to the NULL object. Check for NULL object in the tracepoint and if so, set debug_id to MAX_UINT as was done in 2908f5e101e3. The following oops was seen with xfstests generic/100. BUG: kernel NULL pointer dereference, address: 0000000000000010 ... RIP: 0010:trace_event_raw_event_cachefiles_unlink+0x4e/0xa0 [cachefiles] ... Call Trace: cachefiles_bury_object+0x242/0x430 [cachefiles] ? __vfs_removexattr_locked+0x10f/0x150 ? vfs_removexattr+0x51/0xd0 cachefiles_cull+0x84/0x120 [cachefiles] cachefiles_daemon_cull+0xd1/0x120 [cachefiles] cachefiles_daemon_write+0x158/0x190 [cachefiles] vfs_write+0xbc/0x260 ksys_write+0x4f/0xc0 do_syscall_64+0x3b/0x90 The following oops was seen with xfstests generic/290. BUG: kernel NULL pointer dereference, address: 0000000000000010 ... RIP: 0010:trace_event_raw_event_cachefiles_rename+0x54/0xa0 [cachefiles] ... Call Trace: cachefiles_bury_object+0x35c/0x430 [cachefiles] cachefiles_cull+0x84/0x120 [cachefiles] cachefiles_daemon_cull+0xd1/0x120 [cachefiles] cachefiles_daemon_write+0x158/0x190 [cachefiles] vfs_write+0xbc/0x260 ksys_write+0x4f/0xc0 do_syscall_64+0x3b/0x90 Fixes: 2908f5e101e3 ("fscache: Add a cookie debug ID and use that in traces") Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://listman.redhat.com/archives/linux-cachefs/2021-October/msg00009.html
2021-10-05drm/i915: Extend the async flip VT-d w/a to skl/bxtVille Syrjälä2-0/+17
Looks like skl/bxt/derivatives also need the plane stride stretch w/a when using async flips and VT-d is enabled, or else we get corruption on screen. To my surprise this was even documented in bspec, but only as a note on the CHICHKEN_PIPESL register description rather than on the w/a list. So very much the same thing as on HSW/BDW, except the bits moved yet again. Cc: stable@vger.kernel.org Cc: Karthik B S <karthik.b.s@intel.com> Fixes: 55ea1cb178ef ("drm/i915: Enable async flips in i915") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930190943.17547-1-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit d08df3b0bdb25546e86dc9a6c4e3ec0c43832299) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05drm/i915/bdb: Fix version checkLukasz Majczak2-6/+21
With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+" the size of bdb_lfp_backlight_data structure has been increased, causing if-statement in the parse_lfp_backlight function that comapres this structure size to the one retrieved from BDB, always to fail for older revisions. This patch calculates expected size of the structure for a given BDB version and compares it with the value gathered from BDB. Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221) Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+") Tested-by: Lukasz Majczak <lma@semihalf.com> Signed-off-by: Lukasz Majczak <lma@semihalf.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930134606.227234-1-lma@semihalf.com (cherry picked from commit 4378daf5d04eed59724e6d0e74755e17dce2e105) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05drm/i915/tc: Fix TypeC port init/resume time sanitizationImre Deak3-18/+20
Atm during driver loading and system resume TypeC ports are accessed before their HW/SW state is synced. Move the TypeC port sanitization to the encoder's sync_state hook to fix this. v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well (Jose, Jani) Fixes: f9e76a6e68d3 ("drm/i915: Add an encoder hook to sanitize its state during init/resume") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929132833.2253961-1-imre.deak@intel.com (cherry picked from commit 7194dc998dfffca096c30b3cd39625158608992d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05drm/i915: Fix runtime pm handling in i915_gem_shrinkMaarten Lankhorst1-2/+5
We forgot to call intel_runtime_pm_put on error, fix it! Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v5.13+ Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210830121006.2978297-9-maarten.lankhorst@linux.intel.com (cherry picked from commit 239f3c2ee18376587026efecaea5250fa5926d20) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05drm/i915/audio: Use BIOS provided value for RKL HDA linkKai-Heng Feng1-2/+3
Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver") makes HDMI audio on Lenovo P350 disappear. So in addition to TGL, extend the logic to RKL to use BIOS provided value to fix the regression. Fixes: 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver") Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210906041300.508458-1-kai.heng.feng@canonical.com (cherry picked from commit c6b40ee330fe09b332715bb7ec1467e4fcbe2e65) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05xen/x86: adjust data placementJan Beulich2-3/+5
Both xen_pvh and xen_start_flags get written just once early during init. Using the respective annotation then allows the open-coded placing in .data to go away. Additionally the former, like the latter, wants exporting, or else xen_pvh_domain() can't be used from modules. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/8155ed26-5a1d-c06f-42d8-596d26e75849@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05x86/PVH: adjust function/data placementJan Beulich1-6/+6
Two of the variables can live in .init.data, allowing the open-coded placing in .data to go away. Another "variable" is used to communicate a size value only to very early assembly code, which hence can be both const and live in .init.*. Additionally two functions were lacking __init annotations. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/3b0bb22e-43f4-e459-c5cb-169f996b5669@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: hook up xen_banner() also for PVHJan Beulich4-11/+16
This was effectively lost while dropping PVHv1 code. Move the function and arrange for it to be called the same way as done in PV mode. Clearly this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad check that was recently removed, as that's a PV-only feature. Since the string pointed at by pv_info.name describes the mode, drop "paravirtualized" from the log message while moving the code. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/de03054d-a20d-2114-bb86-eec28e17b3b8@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: generalize preferred console model from PV to PVH Dom0Jan Beulich4-7/+18
Without announcing hvc0 as preferred it won't get used as long as tty0 gets registered earlier. This is particularly problematic with there not being any screen output for PVH Dom0 when the screen is in graphics mode, as the necessary information doesn't get conveyed yet from the hypervisor. Follow PV's model, but be conservative and do this for Dom0 only for now. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/582328b6-c86c-37f3-d802-5539b7a86736@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: make "earlyprintk=xen" work for HVM/PVH DomUJan Beulich2-4/+2
xenboot_write_console() is dealing with these quite fine so I don't see why xenboot_console_setup() would return -ENOENT in this case. Adjust documentation accordingly. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/3d212583-700e-8b2d-727a-845ef33ac265@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: allow "earlyprintk=xen" to work for PV Dom0Jan Beulich1-1/+1
With preferred consoles "tty" and "hvc" announced as preferred, registering "xenboot" early won't result in use of the console: It also needs to be registered as preferred. Generalize this from being DomU- only so far. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/d4a34540-a476-df2c-bca6-732d0d58c5f0@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: make "earlyprintk=xen" work better for PVH Dom0Jan Beulich1-5/+4
The xen_hvm_early_write() path better wouldn't be taken in this case; while port 0xE9 can be used, the hypercall path is quite a bit more efficient. Put that first, as it may also work for DomU-s (see also xen_raw_console_write()). While there also bail from the function when the first domU_write_console() failed - later ones aren't going to succeed. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/4fd89dcb-cfc5-c740-2e94-bb271e432d3e@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: allow PVH Dom0 without XEN_PV=yJan Beulich8-37/+49
Decouple XEN_DOM0 from XEN_PV, converting some existing uses of XEN_DOM0 to a new XEN_PV_DOM0. (I'm not convinced all are really / should really be PV-specific, but for starters I've tried to be conservative.) For PVH Dom0 the hypervisor populates MADT with only x2APIC entries, so without x2APIC support enabled in the kernel things aren't going to work very well. (As opposed, DomU-s would only ever see LAPIC entries in MADT as of now.) Note that this then requires PVH Dom0 to be 64-bit, as X86_X2APIC depends on X86_64. In the course of this xen_running_on_version_or_later() needs to be available more broadly. Move it from a PV-specific to a generic file, considering that what it does isn't really PV-specific at all anyway. Note that xen/interface/version.h cannot be included on its own; in enlighten.c, which uses SCHEDOP_* anyway, include xen/interface/sched.h first to resolve the apparently sole missing type (xen_ulong_t). Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/983bb72f-53df-b6af-14bd-5e088bd06a08@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: prevent PVH type from getting clobberedJan Beulich1-5/+4
Like xen_start_flags, xen_domain_type gets set before .bss gets cleared. Hence this variable also needs to be prevented from getting put in .bss, which is possible because XEN_NATIVE is an enumerator evaluating to zero. Any use prior to init_hvm_pv_info() setting the variable again would lead to wrong decisions; one such case is xenboot_console_setup() when called as a result of "earlyprintk=xen". Use __ro_after_init as more applicable than either __section(".data") or __read_mostly. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/d301677b-6f22-5ae6-bd36-458e1f323d0b@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05arm64: dts: imx8m*-venice-gw7902: fix M2_RST# gpioTim Harvey2-2/+2
Fix invalid M2_RST# gpio pinmux. Fixes: ef484dfcf6f7 ("arm64: dts: imx: Add i.mx8mm/imx8mn Gateworks gw7902 dts support") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-10-05xen/privcmd: drop "pages" parameter from xen_remap_pfn()Jan Beulich3-13/+9
The function doesn't use it and all of its callers say in a comment that their respective arguments are to be non-NULL only in auto-translated mode. Since xen_remap_domain_mfn_array() isn't supposed to be used by non-PV, drop the parameter there as well. It was bogusly passed as non- NULL (PRIV_VMA_LOCKED) by its only caller anyway. For xen_remap_domain_gfn_range(), otoh, it's not clear at all why this wouldn't want / might not need to gain auto-translated support down the road, so the parameter is retained there despite now remaining unused (and the only caller passing NULL); correct a respective comment as well. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/036ad8a2-46f9-ac3d-6219-bdc93ab9e10b@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/privcmd: fix error handling in mmap-resource processingJan Beulich1-3/+4
xen_pfn_t is the same size as int only on 32-bit builds (and not even on Arm32). Hence pfns[] can't be used directly to read individual error values returned from xen_remap_domain_mfn_array(); every other error indicator would be skipped/ignored on 64-bit. Fixes: 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") Cc: stable@vger.kernel.org Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/aa6d6a67-6889-338a-a910-51e889f792d5@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/privcmd: replace kcalloc() by kvcalloc() when allocating empty pagesJan Beulich1-3/+3
Osstest has been suffering test failures for a little while from order-4 allocation failures, resulting from alloc_empty_pages() calling kcalloc(). As there's no need for physically contiguous space here, switch to kvcalloc(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/6d698901-98a4-05be-c421-bcd0713f5335@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05ARM: imx6: disable the GIC CPU interface before calling stby-poweroff sequenceOleksij Rempel1-0/+2
Any pending interrupt can prevent entering standby based power off state. To avoid it, disable the GIC CPU interface. Fixes: 8148d2136002 ("ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-10-05scsi: iscsi: Fix iscsi_task use after freeMike Christie1-6/+9
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsi_task use after free, because the common cleanup code will do a put on the iscsi_task. This reverts the goto and moves the iscsi_get_conn() to after we've checked if the iscsi_task is valid. Link: https://lore.kernel.org/r/20211004210608.9962-1-michael.christie@oracle.com Fixes: d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-05scsi: lpfc: Fix memory overwrite during FC-GS I/O abort handlingJames Smart1-4/+7
When an FC-GS I/O is aborted by lpfc, the driver requires a node pointer for a dereference operation. In the abort I/O routine, the driver miscasts a context pointer to the wrong data type and overwrites a single byte outside of the allocated space. This miscast is done in the abort I/O function handler because the handler works on both FC-GS and FC-LS commands. However, the code neglected to get the correct job location for the node. Fix this by acquiring the necessary node pointer from the correct job structure depending on the I/O type. Link: https://lore.kernel.org/r/20211004231210.35524-1-jsmart2021@gmail.com Co-developed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-05scsi: elx: efct: Delete stray unlock statementDan Carpenter1-2/+1
It's not holding the lock at this stage and the IRQ "flags" are not correct so it would restore something bogus. Delete the unlock statement. Link: https://lore.kernel.org/r/20211004103851.GE25015@kili Fixes: 3e6414003bf9 ("scsi: elx: efct: SCSI I/O handling routines") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-05scsi: ufs: core: Fix task management completionAdrian Hunter2-30/+23
The UFS driver uses blk_mq_tagset_busy_iter() when identifying task management requests to complete, however blk_mq_tagset_busy_iter() doesn't work. blk_mq_tagset_busy_iter() only iterates requests dispatched by the block layer. That appears as if it might have started since commit 37f4a24c2469 ("blk-mq: centralise related handling into blk_mq_get_driver_tag") which removed 'data->hctx->tags->rqs[rq->tag] = rq' from blk_mq_rq_ctx_init() which gets called: blk_get_request blk_mq_alloc_request __blk_mq_alloc_request blk_mq_rq_ctx_init Since UFS task management requests are not dispatched by the block layer, hctx->tags->rqs[rq->tag] remains NULL, and since blk_mq_tagset_busy_iter() relies on finding requests using hctx->tags->rqs[rq->tag], UFS task management requests are never found by blk_mq_tagset_busy_iter(). By using blk_mq_tagset_busy_iter(), the UFS driver was relying on internal details of the block layer, which was fragile and subsequently got broken. Fix by removing the use of blk_mq_tagset_busy_iter() and having the driver keep track of task management requests. Link: https://lore.kernel.org/r/20210922091059.4040-1-adrian.hunter@intel.com Fixes: 1235fc569e0b ("scsi: ufs: core: Fix task management request completion timeout") Fixes: 69a6c269c097 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs") Cc: stable@vger.kernel.org Tested-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-05scsi: acornscsi: Remove scsi_cmd_to_tag() referenceJohn Garry1-1/+1
Commit 756fb6a895af ("scsi: acornscsi: Remove tagged queuing vestiges") mistakenly introduced a reference to function scsi_cmd_to_tag(). This function does not exist as it was removed from an earlier series version when I upstreamed the named commit - originally authored By Hannes - but this reference still remained. Fix by replacing the reference to scsi_cmd_to_tag() with scsi_cmd_to_rq(scsi_scmd)->tag, which scsi_cmd_to_tag() was a wrapper for. Link: https://lore.kernel.org/r/1633002717-79765-1-git-send-email-john.garry@huawei.com Fixes: 756fb6a895af ("scsi: acornscsi: Remove tagged queuing vestiges") Reported-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-05riscv: Flush current cpu icache before other cpusAlexandre Ghiti1-0/+2
On SiFive Unmatched, I recently fell onto the following BUG when booting: [ 0.000000] ftrace: allocating 36610 entries in 144 pages [ 0.000000] Oops - illegal instruction [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5 [ 0.000000] Hardware name: SiFive HiFive Unmatched A00 (DT) [ 0.000000] epc : riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10 [ 0.000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000 [ 0.000000] t1 : 0000000000000004 t2 : 0000000000000000 s0 : ffffffff81803e60 [ 0.000000] s1 : 0000000000000000 a0 : ffffffff81a22238 a1 : ffffffff81803e10 [ 0.000000] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.000000] a5 : 0000000000000000 a6 : ffffffff8000989c a7 : 0000000052464e43 [ 0.000000] s2 : ffffffff81a220c8 s3 : 0000000000000000 s4 : 0000000000000000 [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001 [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000 [ 0.000000] s11: 0000000000000004 t3 : 0000000000000001 t4 : 0000000000000008 [ 0.000000] t5 : ffffffcf04000808 t6 : ffffffe3ffddf188 [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000002 [ 0.000000] [<ffffffff80007240>] riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] [<ffffffff80009474>] sbi_remote_fence_i+0x1e/0x26 [ 0.000000] [<ffffffff8000b8f4>] flush_icache_all+0x12/0x1a [ 0.000000] [<ffffffff8000666c>] patch_text_nosync+0x26/0x32 [ 0.000000] [<ffffffff8000884e>] ftrace_init_nop+0x52/0x8c [ 0.000000] [<ffffffff800f051e>] ftrace_process_locs.isra.0+0x29c/0x360 [ 0.000000] [<ffffffff80a0e3c6>] ftrace_init+0x80/0x130 [ 0.000000] [<ffffffff80a00f8c>] start_kernel+0x5c4/0x8f6 [ 0.000000] ---[ end trace f67eb9af4d8d492b ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- While ftrace is looping over a list of addresses to patch, it always failed when patching the same function: riscv_cpuid_to_hartid_mask. Looking at the backtrace, the illegal instruction is encountered in this same function. However, patch_text_nosync, after patching the instructions, calls flush_icache_range. But looking at what happens in this function: flush_icache_range -> flush_icache_all -> sbi_remote_fence_i -> __sbi_rfence_v02 -> riscv_cpuid_to_hartid_mask The icache and dcache of the current cpu are never synchronized between the patching of riscv_cpuid_to_hartid_mask and calling this same function. So fix this by flushing the current cpu's icache before asking for the other cpus to do the same. Signed-off-by: Alexandre Ghiti <alex@ghiti.fr> Fixes: fab957c11efe ("RISC-V: Atomic and Locking Code") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-10-05Merge remote-tracking branch 'palmer/riscv-clone3' into fixesPalmer Dabbelt1-1/+2
This contains a single patch to properly implement clone3() on rv32, which was missing before. In theory this is a new feature, but it's fixing a warning in checksyscalls that's now causing my build to fail so I'm calling it a fix.
2021-10-05RISC-V: Include clone3() on rv32Palmer Dabbelt1-1/+2
As far as I can tell this should be enabled on rv32 as well, I'm not sure why it's rv64-only. checksyscalls is complaining about our lack of clone3() on rv32. Fixes: 56ac5e213933 ("riscv: enable sys_clone3 syscall for rv64") Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-10-05Merge tag 'linux-kselftest-fixes-5.15-rc5' of ↵Linus Torvalds1-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull Kselftest fixes from Shuah Khan: "A fix to implicit declaration warns in drivers/dma-buf test" * tag 'linux-kselftest-fixes-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: selftests: drivers/dma-buf: Fix implicit declaration warns
2021-10-05fscache: Remove an unused static variableDavid Howells1-1/+0
The fscache object CREATE_OBJECT work state isn't ever referred to, so remove it and avoid the unused variable warning caused by W=1. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
2021-10-05fscache: Fix some kerneldoc warnings shown up by W=1David Howells2-0/+4
Fix some kerneldoc warnings in the fscache driver that are shown up by W=1. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: Mauro Carvalho Chehab <mchehab@kernel.org> cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
2021-10-059p: Fix a bunch of kerneldoc warnings shown up by W=1David Howells7-52/+60
Fix a bunch of kerneldoc warnings shown up by W=1 in the 9p filesystem: (1) Add/remove/fix kerneldoc parameters descriptions. (2) Move __add_fid() from between v9fs_fid_add() and its comment. (3) 9p's caches_show() doesn't really make sense as an API function, so remove the kerneldoc annotation. It's also not prefixed with 'v9fs_'. Also remove the kerneldoc markers from the 9p fscache wrappers. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Dominique Martinet <asmadeus@codewreck.org> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: Mauro Carvalho Chehab <mchehab@kernel.org> cc: v9fs-developer@lists.sourceforge.net cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
2021-10-05afs: Fix kerneldoc warning shown up by W=1David Howells1-2/+2
Fix a kerneldoc warning in afs due to a partially documented internal function by removing the kerneldoc marker. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
2021-10-05nfs: Fix kerneldoc warning shown up by W=1David Howells1-1/+0
Fix a kerneldoc warning in nfs due to documentation for a parameter that isn't present. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: Trond Myklebust <trond.myklebust@hammerspace.com> cc: Anna Schumaker <anna.schumaker@netapp.com> cc: Mauro Carvalho Chehab <mchehab@kernel.org> cc: linux-nfs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-29 13:09:33 +0300