summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-03-05usb: dwc3: of-simple: Add compatible for hi3798mv200 DWC3 controllerYang Xiwen
Hi3798MV200 uses dwc3 controller with a few more clocks and a dedicated resets. Use of_simple driver for it. Signed-off-by: Yang Xiwen <forbidden405@outlook.com> Link: https://lore.kernel.org/r/20240225-dwc3-v4-2-8c1fd6c6f615@outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05dt-bindings: usb: add hisilicon,hi3798mv200-dwc3Yang Xiwen
Document the DWC3 controller used by Hi3798MV200. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Yang Xiwen <forbidden405@outlook.com> Link: https://lore.kernel.org/r/20240225-dwc3-v4-1-8c1fd6c6f615@outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: port: Don't try to peer unused USB ports based on locationMathias Nyman
Unused USB ports may have bogus location data in ACPI PLD tables. This causes port peering failures as these unused USB2 and USB3 ports location may match. Due to these failures the driver prints a "usb: port power management may be unreliable" warning, and unnecessarily blocks port power off during runtime suspend. This was debugged on a couple DELL systems where the unused ports all returned zeroes in their location data. Similar bugreports exist for other systems. Don't try to peer or match ports that have connect type set to USB_PORT_NOT_USED. Fixes: 3bfd659baec8 ("usb: find internal hub tier mismatch via acpi") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218465 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218486 Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/linux-usb/5406d361-f5b7-4309-b0e6-8c94408f7d75@molgen.mpg.de Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218490 Link: https://lore.kernel.org/r/20240222233343.71856-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: gadget: ncm: Fix handling of zero block length packetsKrishna Kurapati
While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present. According to the NCM spec: "If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent. wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues. wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero. Cc: stable@vger.kernel.org Fixes: 427694cfaafa ("usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call") Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Maciej Żenczykowski <maze@google.com> Link: https://lore.kernel.org/r/20240228115441.2105585-1-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: typec: altmodes/displayport: create sysfs nodes as driver's default ↵RD Babiera
device attribute group The DisplayPort driver's sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases. Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI. Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode") Cc: stable@vger.kernel.org Signed-off-by: RD Babiera <rdbabiera@google.com> Link: https://lore.kernel.org/r/20240229001101.3889432-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: typec: ucsi: Register SOP' alternate modes with cable plugJameson Thies
Register SOP' alternate modes with a Type-C Connector Class cable plug. Alternate modes are queried from the PPM using the GET_ALTERNATE_MODES command with recipient set to SOP'. Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Jameson Thies <jthies@google.com> Link: https://lore.kernel.org/r/20240305025804.1290919-5-jthies@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: typec: ucsi: Register SOP/SOP' Discover Identity ResponsesJameson Thies
Register SOP and SOP' Discover Identity responses with the USB Type-C Connector Class as partner and cable identities, respectively. Discover Identity responses are requested from the PPM using the GET_PD_MESSAGE UCSI command. Signed-off-by: Jameson Thies <jthies@google.com> Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20240305025804.1290919-4-jthies@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: typec: ucsi: Register cables based on GET_CABLE_PROPERTYJameson Thies
Register cables with the Type-C Connector Class in the UCSI driver based on the PPM response to GET_CABLE_PROPERTY. Registered cable properties include plug type, cable type and major revision. Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Jameson Thies <jthies@google.com> Link: https://lore.kernel.org/r/20240305025804.1290919-3-jthies@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: typec: ucsi: Clean up UCSI_CABLE_PROP macrosJameson Thies
Clean up UCSI_CABLE_PROP macros by fixing a bitmask shifting error for plug type and updating the modal support macro for consistent naming. Fixes: 3cf657f07918 ("usb: typec: ucsi: Remove all bit-fields") Cc: stable@vger.kernel.org Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jameson Thies <jthies@google.com> Link: https://lore.kernel.org/r/20240305025804.1290919-2-jthies@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: typec: pd: no opencoding of FIELD_GETOliver Neukum
If we have a neat macro, at least new code should use it. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20240229131851.16148-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: typec: tpcm: Fix PORT_RESET behavior for self powered devicesBadhri Jagan Sridharan
While commit 69f89168b310 ("usb: typec: tpcm: Fix issues with power being removed during reset") fixes the boot issues for bus powered devices such as LibreTech Renegade Elite/Firefly, it trades off the CC pins NOT being Hi-Zed during errory recovery (i.e PORT_RESET) for devices which are NOT bus powered(a.k.a self powered). This change Hi-Zs the CC pins only for self powered devices, thus preventing brown out for bus powered devices Adhering to spec is gaining more importance due to the Common charger initiative enforced by the European Union. Quoting from the spec: 4.5.2.2.2.1 ErrorRecovery State Requirements The port shall not drive VBUS or VCONN, and shall present a high-impedance to ground (above zOPEN) on its CC1 and CC2 pins. Hi-Zing the CC pins is the inteded behavior for PORT_RESET. CC pins are set to default state after tErrorRecovery in PORT_RESET_WAIT_OFF. 4.5.2.2.2.2 Exiting From ErrorRecovery State A Sink shall transition to Unattached.SNK after tErrorRecovery. A Source shall transition to Unattached.SRC after tErrorRecovery. Fixes: 69f89168b310 ("usb: typec: tpcm: Fix issues with power being removed during reset") Cc: stable@vger.kernel.org Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Tested-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240228000512.746252-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: typec: ucsi: fix UCSI on SM8550 & SM8650 Qualcomm devicesNeil Armstrong
On SM8550 and SM8650 Qualcomm platforms a call to UCSI_GET_PDOS for non-PD partners will cause a firmware crash with no easy way to recover from it. Add UCSI_NO_PARTNER_PDOS quirk for those platform until we find a way to properly handle the crash. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240223-topic-sm8550-upstream-ucsi-no-pdos-v1-1-8900ad510944@linaro.org Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05fuse: Convert fuse_writepage_locked to take a folioMatthew Wilcox (Oracle)
The one remaining caller of fuse_writepage_locked() already has a folio, so convert this function entirely. Saves a few calls to compound_head() but no attempt is made to support large folios in this patch. Signed-off-by: "Matthew Wilcox (Oracle)" <willy@infradead.org> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: Remove fuse_writepageMatthew Wilcox (Oracle)
The writepage operation is deprecated as it leads to worse performance under high memory pressure due to folios being written out in LRU order rather than sequentially within a file. Use filemap_migrate_folio() to support dirty folio migration instead of writepage. Signed-off-by: "Matthew Wilcox (Oracle)" <willy@infradead.org> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05usb: typec: altmodes/displayport: send configure message on sop'RD Babiera
When the port is setting the pin configuration when no configuration is chosen, the DisplayPort driver will not send Configure to the cable plug if it's available. Add transition to DP_STATE_CONFIGURE_PRIME. Fixes: 71ba4fe56656 ("usb: typec: altmodes/displayport: add SOP' support") Signed-off-by: RD Babiera <rdbabiera@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240223002302.3937235-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: typec: tcpm: fix SOP' sequences in tcpm_pd_svdmRD Babiera
The Smatch checker flags svdm_version being uninitialized for Discover Identity Messages within tcpm_pd_svdm for the CMDT_INIT case. Cable plugs cannot initialize SVDM commands, however a port partner that isn't allowed to communicate over SOP' could, which would result in the CMDT_INIT block running for a received SOP' message. First, initialize svdm_version for the TCPC_TX_SOP_PRIME case. If the svdm_version returns as an error, we expect the received svdm to be the result of Discover Identity that updates the value accordingly. Next, drop all SOP' messages of type CMDT_INIT within tcpm_pd_svdm. Finally, remove redundant call that assigns modep and pdev. Smatch will raise an uninitialized symbol error over modep_prime and pdev_prime, but both the assignment and use of these variables are guarded behind a check for rx_sop_type == TCPC_TX_SOP_PRIME. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/a432603b-b801-4001-b309-247dded707d3@moroto.mountain/ Fixes: fb7ff25ae433 ("usb: typec: tcpm: add discover identity support for SOP'") Signed-off-by: RD Babiera <rdbabiera@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240223002233.3936275-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: usb-acpi: Set port connect type of not connectable ports correctlyMathias Nyman
Ports with _UPC (USB Port Capability) ACPI objects stating they are "not connectable" are not wired to any connector or internal device. They only exist inside the host controller. These ports may not have an ACPI _PLD (Physical Location of Device) object. Rework the code so that _UPC is read even if _PLD does not exist, and make sure the port->connect_type is set to "USB_PORT_NOT_USED" instead of "USB_PORT_CONNECT_TYPE_UNKNOWN". No bugs or known issues are reported due to possibly not parsing _UPC, and thus leaving the port connect type as "unknown" instead of "not used". Nice to have this fixed but no need to add it to stable kernels, or urgency to get it upstream. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240223140305.185182-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05usb: dwc3: qcom: Remove ACPI support from glue driverKrishna Kurapati
Minimal ACPI support was added to the Qualcomm DWC3 glue driver in order to enable USB on SDM850 and SC8180X compute platforms. The support is still functional, but unnoticed regressions in other drivers indicates that no one actually booting any of platforms dependent on this implementation. The functionality provides is the bare minimum and is not expected to aid in the effort of bringing full ACPI support to the driver in the future. Remove the ACPI code from the Qualcomm DWC3 glue driver to aid in the implementation of improvements that are actually used like multiport and flattening device tree. Commit message by Bjorn Andersson. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240305093216.3814787-1-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05Merge tag 'linux-can-next-for-6.9-20240304' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2024-03-04 this is a pull request of 4 patches for net-next/master. The 1st patch is by Jimmy Assarsson and adds support for the Leaf v3 to the kvaser_usb driver. Martin Jocić's patch targets the kvaser_pciefd driver and adds support for the Kvaser PCIe 8xCAN device. Followed by a patch by me that adds a missing a cpu_to_le32() to the gs_usb driver, the change is not critical as the assigned value is 0. The last patch is also by me and replaces a literal 256 with a proper define. linux-can-next-for-6.9-20240304 * tag 'linux-can-next-for-6.9-20240304' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: mcp251xfd: __mcp251xfd_get_berr_counter(): use CAN_BUS_OFF_THRESHOLD instead of open coding it can: gs_usb: gs_cmd_reset(): use cpu_to_le32() to assign mode can: kvaser_pciefd: Add support for Kvaser PCIe 8xCAN can: kvaser_usb: Add support for Leaf v3 ==================== Link: https://lore.kernel.org/r/20240304092051.3631481-1-mkl@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05net: Re-use and set mono_delivery_time bit for userspace tstamp packetsAbhishek Chauhan
Bridge driver today has no support to forward the userspace timestamp packets and ends up resetting the timestamp. ETF qdisc checks the packet coming from userspace and encounters to be 0 thereby dropping time sensitive packets. These changes will allow userspace timestamps packets to be forwarded from the bridge to NIC drivers. Setting the same bit (mono_delivery_time) to avoid dropping of userspace tstamp packets in the forwarding path. Existing functionality of mono_delivery_time remains unaltered here, instead just extended with userspace tstamp support for bridge forwarding path. Signed-off-by: Abhishek Chauhan <quic_abchauha@quicinc.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20240301201348.2815102-1-quic_abchauha@quicinc.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05virtio_fs: remove duplicate check if queue is brokenLi RongQing
virtqueue_enable_cb() will call virtqueue_poll() which will check if queue is broken at beginning, so remove the virtqueue_is_broken() call Signed-off-by: Li RongQing <lirongqing@baidu.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: use FUSE_ROOT_ID in fuse_get_root_inode()Miklos Szeredi
...when calling fuse_iget(). Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: don't unhash rootMiklos Szeredi
The root inode is assumed to be always hashed. Do not unhash the root inode even if it is marked BAD. Fixes: 5d069dbe8aaf ("fuse: fix bad inode") Cc: <stable@vger.kernel.org> # v5.11 Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: fix root lookup with nonzero generationMiklos Szeredi
The root inode has a fixed nodeid and generation (1, 0). Prior to the commit 15db16837a35 ("fuse: fix illegal access to inode with reused nodeid") generation number on lookup was ignored. After this commit lookup with the wrong generation number resulted in the inode being unhashed. This is correct for non-root inodes, but replacing the root inode is wrong and results in weird behavior. Fix by reverting to the old behavior if ignoring the generation for the root inode, but issuing a warning in dmesg. Reported-by: Antonio SJ Musumeci <trapexit@spawn.link> Closes: https://lore.kernel.org/all/CAOQ4uxhek5ytdN8Yz2tNEOg5ea4NkBb4nk0FGPjPk_9nz-VG3g@mail.gmail.com/ Fixes: 15db16837a35 ("fuse: fix illegal access to inode with reused nodeid") Cc: <stable@vger.kernel.org> # v5.14 Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: replace remaining make_bad_inode() with fuse_make_bad()Miklos Szeredi
fuse_do_statx() was added with the wrong helper. Fixes: d3045530bdd2 ("fuse: implement statx") Cc: <stable@vger.kernel.org> # v6.6 Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05virtiofs: drop __exit from virtio_fs_sysfs_exit()Stefan Hajnoczi
virtio_fs_sysfs_exit() is called by: - static int __init virtio_fs_init(void) - static void __exit virtio_fs_exit(void) Remove __exit from virtio_fs_sysfs_exit() since virtio_fs_init() is not an __exit function. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402270649.GYjNX0yw-lkp@intel.com/ Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: implement passthrough for mmapAmir Goldstein
An mmap request for a file open in passthrough mode, maps the memory directly to the backing file. An mmap of a file in direct io mode, usually uses cached mmap and puts the inode in caching io mode, which denies new passthrough opens of that inode, because caching io mode is conflicting with passthrough io mode. For the same reason, trying to mmap a direct io file, while there is a passthrough file open on the same inode will fail with -ENODEV. An mmap of a file in direct io mode, also needs to wait for parallel dio writes in-progress to complete. If a passthrough file is opened, while an mmap of another direct io file is waiting for parallel dio writes to complete, the wait is aborted and mmap fails with -ENODEV. A FUSE server that uses passthrough and direct io opens on the same inode that may also be mmaped, is advised to provide a backing fd also for the files that are open in direct io mode (i.e. use the flags combination FOPEN_DIRECT_IO | FOPEN_PASSTHROUGH), so that mmap will always use the backing file, even if read/write do not passthrough. Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: implement splice read/write passthroughAmir Goldstein
This allows passing fstests generic/249 and generic/591. Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: implement read/write passthroughAmir Goldstein
Use the backing file read/write helpers to implement read/write passthrough to a backing file. After read/write, we invalidate a/c/mtime/size attributes. Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: implement open in passthrough modeAmir Goldstein
After getting a backing file id with FUSE_DEV_IOC_BACKING_OPEN ioctl, a FUSE server can reply to an OPEN request with flag FOPEN_PASSTHROUGH and the backing file id. The FUSE server should reuse the same backing file id for all the open replies of the same FUSE inode and open will fail (with -EIO) if a the server attempts to open the same inode with conflicting io modes or to setup passthrough to two different backing files for the same FUSE inode. Using the same backing file id for several different inodes is allowed. Opening a new file with FOPEN_DIRECT_IO for an inode that is already open for passthrough is allowed, but only if the FOPEN_PASSTHROUGH flag and correct backing file id are specified as well. The read/write IO of such files will not use passthrough operations to the backing file, but mmap, which does not support direct_io, will use the backing file insead of using the page cache as it always did. Even though all FUSE passthrough files of the same inode use the same backing file as a backing inode reference, each FUSE file opens a unique instance of a backing_file object to store the FUSE path that was used to open the inode and the open flags of the specific open file. The per-file, backing_file object is released along with the FUSE file. The inode associated fuse_backing object is released when the last FUSE passthrough file of that inode is released AND when the backing file id is closed by the server using the FUSE_DEV_IOC_BACKING_CLOSE ioctl. Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: prepare for opening file in passthrough modeAmir Goldstein
In preparation for opening file in passthrough mode, store the fuse_open_out argument in ff->args to be passed into fuse_file_io_open() with the optional backing_id member. This will be used for setting up passthrough to backing file on open reply with FOPEN_PASSTHROUGH flag and a valid backing_id. Opening a file in passthrough mode may fail for several reasons, such as missing capability, conflicting open flags or inode in caching mode. Return EIO from fuse_file_io_open() in those cases. The combination of FOPEN_PASSTHROUGH and FOPEN_DIRECT_IO is allowed - it mean that read/write operations will go directly to the server, but mmap will be done to the backing file. Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05fuse: implement ioctls to manage backing filesAmir Goldstein
FUSE server calls the FUSE_DEV_IOC_BACKING_OPEN ioctl with a backing file descriptor. If the call succeeds, a backing file identifier is returned. A later change will be using this backing file id in a reply to OPEN request with the flag FOPEN_PASSTHROUGH to setup passthrough of file operations on the open FUSE file to the backing file. The FUSE server should call FUSE_DEV_IOC_BACKING_CLOSE ioctl to close the backing file by its id. This can be done at any time, but if an open reply with FOPEN_PASSTHROUGH flag is still in progress, the open may fail if the backing file is closed before the fuse file was opened. Setting up backing files requires a server with CAP_SYS_ADMIN privileges. For the backing file to be successfully setup, the backing file must implement both read_iter and write_iter file operations. The limitation on the level of filesystem stacking allowed for the backing file is enforced before setting up the backing file. Signed-off-by: Alessio Balsini <balsini@android.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2024-03-05Merge branch 'net-gro-cleanups-and-fast-path-refinement'Paolo Abeni
Eric Dumazet says: ==================== net: gro: cleanups and fast path refinement Current GRO stack has a 'fast path' for a subset of drivers, users of napi_frags_skb(). With TCP zerocopy/direct uses, header split at receive is becoming more important, and GRO fast path is disabled. This series makes GRO (a bit) more efficient for almost all use cases. ==================== Link: https://lore.kernel.org/r/20240301193740.3436871-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05tcp: gro: micro optimizations in tcp[4]_gro_complete()Eric Dumazet
In tcp_gro_complete() : Moving the skb->inner_transport_header setting allows the compiler to reuse the previously loaded value of skb->transport_header. Caching skb_shinfo() avoids duplications as well. In tcp4_gro_complete(), doing a single change on skb_shinfo(skb)->gso_type also generates better code. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05net: gro: enable fast path for more casesEric Dumazet
Currently the so-called GRO fast path is only enabled for napi_frags_skb() callers. After the prior patch, we no longer have to clear frag0 whenever we pulled bytes to skb->head. We therefore can initialize frag0 to skb->data so that GRO fast path can be used in the following additional cases: - Drivers using header split (populating skb->data with headers, and having payload in one or more page fragments). - Drivers not using any page frag (entire packet is in skb->data) Add a likely() in skb_gro_may_pull() to help the compiler to generate better code if possible. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05net: gro: change skb_gro_network_header()Eric Dumazet
Change skb_gro_network_header() to accept a const sk_buff and to no longer check if frag0 is NULL or not. This allows to remove skb_gro_frag0_invalidate() which is seen in profiles when header-split is enabled. sk_buff parameter is constified for skb_gro_header_fast(), inet_gro_compute_pseudo() and ip6_gro_compute_pseudo(). Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05net: gro: rename skb_gro_header_hard()Eric Dumazet
skb_gro_header_hard() is renamed to skb_gro_may_pull() to match the convention used by common helpers like pskb_may_pull(). This means the condition is inverted: if (skb_gro_header_hard(skb, hlen)) slow_path(); becomes: if (!skb_gro_may_pull(skb, hlen)) slow_path(); Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05ACPI: CPPC: enable AMD CPPC V2 support for family 17h processorsPerry Yuan
As there are some AMD processors which only support CPPC V2 firmware and BIOS implementation, the amd_pstate driver will be failed to load when system booting with below kernel warning message: [ 0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled To make the amd_pstate driver can be loaded on those TR40 processors, it needs to match x86_model from 0x30 to 0x7F for family 17H. With the change, the system can load amd_pstate driver as expected. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reported-by: Gino Badouri <badouri.g@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218171 Fixes: fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory") Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-03-05thermal: core: Remove excess empty line from a commentFlavio Suligoi
The first and the third lines of the kerneldoc comment for: thermal_zone_device_set_polling() belong to the same sentences, so join them together. Signed-off-by: Flavio Suligoi <f.suligoi@asem.it> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-03-05mmc: tmio: comment the ERR_PTR usage in this driverWolfram Sang
It is not super obvious why the driver sometimes uses an ERR_PTR for the current mrq. Explain why in comments. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20240305105623.3379-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05mmc: mmc_spi: Don't mention DMA directionAndy Shevchenko
Since driver doesn't handle any DMA requests, drop any use of DMA bits, such as DMA direction. Instead, use MMC_DATA_WRITE flag directly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240304184830.1319526-1-andriy.shevchenko@linux.intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05mmc: dw_mmc: Remove unused of_gpio.hAndy Shevchenko
of_gpio.h is deprecated and subject to remove. The driver doesn't use it, simply remove the unused header. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20240304175606.1200076-1-andriy.shevchenko@linux.intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05mmc: dw_mmc: add support for hi3798mv200Yang Xiwen
Add support for Hi3798MV200 specific extension. Signed-off-by: Yang Xiwen <forbidden405@outlook.com> Link: https://lore.kernel.org/r/20240229-b4-mmc-hi3798mv200-v7-5-10c03f316285@outlook.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05dt-bindings: mmc: hisilicon,hi3798cv200-dw-mshc: add Hi3798MV200 bindingYang Xiwen
Add binding and an extra property for Hi3798MV200 DWMMC specific extension. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Yang Xiwen <forbidden405@outlook.com> Link: https://lore.kernel.org/r/20240229-b4-mmc-hi3798mv200-v7-4-10c03f316285@outlook.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05dt-bindings: mmc: dw-mshc-hi3798cv200: convert to YAMLYang Xiwen
convert the legacy txt binding to modern YAML and rename to hisilicon,hi3798cv200-dw-mshc.yaml. No semantic change. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Yang Xiwen <forbidden405@outlook.com> Link: https://lore.kernel.org/r/20240229-b4-mmc-hi3798mv200-v7-3-10c03f316285@outlook.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05mmc: dw_mmc-hi3798cv200: remove MODULE_ALIAS()Yang Xiwen
The alias is not used and should be removed. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Yang Xiwen <forbidden405@outlook.com> Link: https://lore.kernel.org/r/20240229-b4-mmc-hi3798mv200-v7-2-10c03f316285@outlook.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05mmc: core: Use a struct device* as in-param to mmc_of_parse_clk_phase()Yang Xiwen
Parsing dt usually happens very early, sometimes even before the struct mmc_host has been allocated (e.g. dw_mci_probe() and dw_mci_parse_dt() in dw_mmc.c). Looking at the source of mmc_of_parse_clk_phase(), it's actually not needed to have an initialized mmc_host, let's therefore pass a struct device* to it instead. Also update the only current user, sdhci-of-aspeed. Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Yang Xiwen <forbidden405@outlook.com> Link: https://lore.kernel.org/r/20240229-b4-mmc-hi3798mv200-v7-1-10c03f316285@outlook.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05mmc: wmt-sdmmc: remove an incorrect release_mem_region() call in the .remove ↵Christophe JAILLET
function This looks strange to call release_mem_region() in a remove function without any request_mem_region() in the probe or "struct resource" somewhere. So remove the corresponding code. Fixes: 3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/bb0bb1ed1e18de55e8c0547625bde271e64b8c31.1708983064.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05mmc: Merge branch fixes into nextUlf Hansson
Merge the mmc fixes for v6.8-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.9. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-03-05mmc: tmio: avoid concurrent runs of mmc_request_done()Wolfram Sang
With the to-be-fixed commit, the reset_work handler cleared 'host->mrq' outside of the spinlock protected critical section. That leaves a small race window during execution of 'tmio_mmc_reset()' where the done_work handler could grab a pointer to the now invalid 'host->mrq'. Both would use it to call mmc_request_done() causing problems (see link below). However, 'host->mrq' cannot simply be cleared earlier inside the critical section. That would allow new mrqs to come in asynchronously while the actual reset of the controller still needs to be done. So, like 'tmio_mmc_set_ios()', an ERR_PTR is used to prevent new mrqs from coming in but still avoiding concurrency between work handlers. Reported-by: Dirk Behme <dirk.behme@de.bosch.com> Closes: https://lore.kernel.org/all/20240220061356.3001761-1-dirk.behme@de.bosch.com/ Fixes: df3ef2d3c92c ("mmc: protect the tmio_mmc driver against a theoretical race") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Reviewed-by: Dirk Behme <dirk.behme@de.bosch.com> Cc: stable@vger.kernel.org # 3.0+ Link: https://lore.kernel.org/r/20240305104423.3177-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>