- 28 Jun, 2021 8 commits
-
-
Uwe Kleine-König authored
Since the PWM core uses device links (commit b2c200e3 ("pwm: Add consumer device link")) each consumer driver that requested the PWMs is already gone. If they called pwm_put() (as they should) the PWMF_REQUESTED bit is not set. If they failed (which is a bug) the PWMF_REQUESTED bit might still be set, but the driver that cared is gone, so nothing bad happens if the PWM chip goes away even if the PWMF_REQUESTED is still present. So the check can be dropped. With this change pwmchip_remove() returns always 0, so lowlevel drivers don't need to check the return code any more. Once all drivers dropped this check this function can be changed to return void. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
With devm_pwmchip_add() we can drop pwmchip_remove() from the device remove callback. The latter can then go away, too and as this is the only user of platform_get_drvdata(), the respective call to platform_set_drvdata() can go, too. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Uwe Kleine-König authored
With devm_pwmchip_add() we can drop pwmchip_remove() from the device remove callback. The latter can then go away, too and as this is the only user of platform_get_drvdata(), the respective call to platform_set_drvdata() can go, too. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback disables clocks that were not enabled in .probe(). So just probing and then unbinding the driver results in a clk enable imbalance. So just drop the call to disable the clocks. (Which BTW was also in the wrong order because the call makes the PWM unfunctional and so should have come only after pwmchip_remove()). Fixes: 9f4c8f96 ("pwm: imx: Add ipg clock operation") Signed-off-by:
-
Uwe Kleine-König authored
With devm_pwmchip_add() we can drop pwmchip_remove() from the device remove callback. The latter can then go away, too and as this is the only user of platform_get_drvdata(), the respective call to platform_set_drvdata() can go, too. Signed-off-by:
-
Uwe Kleine-König authored
Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Uwe Kleine-König authored
Signed-off-by:
-
Uwe Kleine-König authored
This potentially simplifies low-level PWM drivers. Signed-off-by:
-
- 04 Jun, 2021 6 commits
-
-
Lokesh Vutla authored
Add compatible string for AM64 SoC in device tree binding. EPWM IP in AM64 does not support High resolution, so named epwm instead of ehrpwm in compatible. However IP is till compatible with features supported by driver with ti,am3352-ehrpwm compatible. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Lokesh Vutla authored
Convert the tiehrpwm binding to DT schema format using json-schema. Along with this conversion the following changes are included: - 'clock' and 'clock-names' properties are marked as required as driver fails to probe without these properties - Dropped ti,am33xx-ehrpwm as it is no longer applicable. - 'power-domains' property is introduced and marked as optional. Signed-off-by:
-
Clemens Gruber authored
Regmap operations can fail if the underlying subsystem is not working properly (e.g. hogged I2C bus, etc.) As this is useful information for the user, print an error message if it happens. Let probe fail if the first regmap_read or the first regmap_write fails. Signed-off-by:
Clemens Gruber <clemens.gruber@pqgruber.com> Signed-off-by:
-
Clemens Gruber authored
Previously, the last used PWM channel could change the global prescale setting, even if other channels are already in use. Fix it by only allowing the first enabled PWM to change the global chip-wide prescale setting. If there is more than one channel in use, the prescale settings resulting from the chosen periods must match. GPIOs do not count as enabled PWMs as they are not using the prescaler and can't change it. Signed-off-by:
-
Clemens Gruber authored
If usage_power is set, the pca9685 driver will phase shift the individual channels relative to their channel number. This improves EMI because the enabled channels no longer turn on at the same time, while still maintaining the configured duty cycle / power output. Signed-off-by:
-
Clemens Gruber authored
If usage_power is set, the PWM driver is only required to maintain the power output but has more freedom regarding signal form. If supported, the signal can be optimized, for example to improve EMI by phase shifting individual channels. Signed-off-by:
-
- 25 May, 2021 8 commits
-
-
Uwe Kleine-König authored
Just using the previous callbacks to implment a similar procedure as the legacy handling in the core. Signed-off-by:
-
Uwe Kleine-König authored
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clocks. The check for pwmchip_remove()'s return value is dropped as this function returns effectively always 0 and returning an error in a remove callback is useless anyhow (as the device core ignores it and drops devm allocated resources). Signed-off-by:
-
Uwe Kleine-König authored
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by:
-
Uwe Kleine-König authored
With the original code a request for period = 65536000 ns and period = 32768000 ns yields the same register settings (which results in 32768000 ns) because the value for pwmc0 was miscalculated. Also simplify using that fls(0) is 0. Fixes: 721b5957 ("pwm: visconti: Add Toshiba Visconti SoC PWM support") Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by:
-
Uwe Kleine-König authored
With the previous commit there is no need for the lowlevel driver any more to specify it it uses two or three cells. So simplify accordingly. The only non-trival change affects the pwm-rockchip driver: It used to only support three cells if the hardware supports polarity. Now the default number depends on the device tree which has to match hardware anyhow (and if it doesn't the error is just a bit delayed as a PWM handle with an inverted setting is catched when pwm_apply_state() is called). Signed-off-by:
-
Uwe Kleine-König authored
This allows to simplify all drivers that use three pwm-cells. The only ugly side effect is that if a driver specified of_pwm_n_cells = 2 it suddenly supports device trees that use #pwm-cells = <3>. This however isn't a bad thing because the driver doesn't need explicit support for three cells as the core handles all the details. Also there is no such in-tree driver. Signed-off-by:
-
Uwe Kleine-König authored
Since the previous commit the latter function can do everything that the former does. So simplify accordingly. Signed-off-by:
-
Uwe Kleine-König authored
The two functions of_pwm_simple_xlate() and of_pwm_xlate_with_flags() are quite similar. of_pwm_simple_xlate() only supports two-cell PWM specifiers while of_pwm_xlate_with_flags() only supports PWM specifiers with 3 or more cells. The latter can easily be modified to behave identically to of_pwm_simple_xlate() for two-cell PWM specifiers. This is implemented here and allows to drop of_pwm_simple_xlate() in the next commit. There is a small detail that is different now in the two-cell specifier case in of_pwm_xlate_with_flags(): pwm->args.polarity is unconditionally initialized to PWM_POLARITY_NORMAL in the latter. I didn't find a case where this matters and doing that explicitly is the more robust approach. Signed-off-by:
-
- 09 May, 2021 10 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Commit b9d79e4c ("fbmem: Mark proc_fb_seq_ops as __maybe_unused") places the '__maybe_unused' in an entirely incorrect location between the "struct" keyword and the structure name. It's a wonder that gcc accepts that silently, but clang quite reasonably warns about it: drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute declaration must precede definition [-Wignored-attributes] static const struct __maybe_unused seq_operations proc_fb_seq_ops = { ^ Fix it. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Bit later than usual, I queued them all up on Friday then promptly forgot to write the pull request email. This is mainly amdgpu fixes, with some radeon/msm/fbdev and one i915 gvt fix thrown in. amdgpu: - MPO hang workaround - Fix for concurrent VM flushes on vega/navi - dcefclk is not adjustable on navi1x and newer - MST HPD debugfs fix - Suspend/resumes fixes - Register VGA clients late in case driver fails to load - Fix GEM leak in user framebuffer create - Add support for polaris12 with 32 bit memory interface - Fix duplicate cursor issue when using overlay - Fix corruption with tiled surfaces on VCN3 - Add BO size and stride check to fix BO size verification radeon: - Fix off-by-one in power state parsing - Fix possible memory leak in power state parsing msm: - NULL ptr dereference fix fbdev: - procfs disabled warning fix i915: - gvt: Fix a possible division by zero in vgpu display rate calculation" * tag 'drm-next-2021-05-10' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: Use device specific BO size & stride check. drm/amdgpu: Init GFX10_ADDR_CONFIG for VCN v3 in DPG mode. drm/amd/pm: initialize variable drm/radeon: Avoid power table parsing memory leaks drm/radeon: Fix off-by-one power_state index heap overwrite drm/amd/display: Fix two cursor duplication when using overlay drm/amdgpu: add new MC firmware for Polaris12 32bit ASIC fbmem: Mark proc_fb_seq_ops as __maybe_unused drm/msm/dpu: Delete bonkers code drm/i915/gvt: Prevent divided by zero when calculating refresh rate amdgpu: fix GEM obj leak in amdgpu_display_user_framebuffer_create drm/amdgpu: Register VGA clients after init can no longer fail drm/amdgpu: Handling of amdgpu_device_resume return value for graceful teardown drm/amdgpu: fix r initial values drm/amd/display: fix wrong statement in mst hpd debugfs amdgpu/pm: set pp_dpm_dcefclk to readonly on NAVI10 and newer gpus amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID drm/amdgpu: fix concurrent VM flushes on Vega/Navi v2 drm/amd/display: Reject non-zero src_y and src_x for video planes -
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fix from Jens Axboe: "Turns out the bio max size change still has issues, so let's get it reverted for 5.13-rc1. We'll shake out the issues there and defer it to 5.14 instead" * tag 'block-5.13-2021-05-09' of git://git.kernel.dk/linux-block: Revert "bio: limit bio max size"
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull cifs fixes from Steve French: "Three small SMB3 chmultichannel related changesets (also for stable) from the SMB3 test event this week. The other fixes are still in review/testing" * tag '5.13-rc-smb3-part3' of git://git.samba.org/sfrench/cifs-2.6: smb3: if max_channels set to more than one channel request multichannel smb3: do not attempt multichannel to server which does not support it smb3: when mounting with multichannel include it in requested capabilities
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fixes from Thomas Gleixner: "A set of scheduler updates: - Prevent PSI state corruption when schedule() races with cgroup move. A recent commit combined two PSI callbacks to reduce the number of cgroup tree updates, but missed that schedule() can drop rq::lock for load balancing, which opens the race window for cgroup_move_task() which then observes half updated state. The fix is to solely use task::ps_flags instead of looking at the potentially mismatching scheduler state - Prevent an out-of-bounds access in uclamp caused bu a rounding division which can lead to an off-by-one error exceeding the buckets array size. - Prevent unfairness caused by missing load decay when a task is attached to a cfs runqueue. The old load of the task was attached to the runqueue and never removed. Fix it by enforcing the load update through the hierarchy for unthrottled run queue instances. - A documentation fix fot the 'sched_verbose' command line option" * tag 'sched-urgent-2021-05-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Fix unfairness caused by missing load decay sched: Fix out-of-bound access in uclamp psi: Fix psi state corruption when schedule() races with cgroup move sched,doc: sched_debug_verbose cmdline should be sched_verbose -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull locking fixes from Thomas Gleixner: "A set of locking related fixes and updates: - Two fixes for the futex syscall related to the timeout handling. FUTEX_LOCK_PI does not support the FUTEX_CLOCK_REALTIME bit and because it's not set the time namespace adjustment for clock MONOTONIC is applied wrongly. FUTEX_WAIT cannot support the FUTEX_CLOCK_REALTIME bit because its always a relative timeout. - Cleanups in the futex syscall entry points which became obvious when the two timeout handling bugs were fixed. - Cleanup of queued_write_lock_slowpath() as suggested by Linus - Fixup of the smp_call_function_single_async() prototype" * tag 'locking-urgent-2021-05-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Make syscall entry points less convoluted futex: Get rid of the val2 conditional dance futex: Do not apply time namespace adjustment on FUTEX_LOCK_PI Revert 337f1304 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") locking/qrwlock: Cleanup queued_write_lock_slowpath() smp: Fix smp_call_function_single_async prototype -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 perf fix from Borislav Petkov: "Handle power-gating of AMD IOMMU perf counters properly when they are used" * tag 'perf_urgent_for_v5.13_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/events/amd/iommu: Fix invalid Perf result due to IOMMU PMC power-gating
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Borislav Petkov: "A bunch of things accumulated for x86 in the last two weeks: - Fix guest vtime accounting so that ticks happening while the guest is running can also be accounted to it. Along with a consolidation to the guest-specific context tracking helpers. - Provide for the host NMI handler running after a VMX VMEXIT to be able to run on the kernel stack correctly. - Initialize MSR_TSC_AUX when RDPID is supported and not RDTSCP (virt relevant - real hw supports both) - A code generation improvement to TASK_SIZE_MAX through the use of alternatives - The usual misc and related cleanups and improvements" * tag 'x86_urgent_for_v5.13_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: KVM: x86: Consolidate guest enter/exit logic to common helpers context_tracking: KVM: Move guest enter/exit wrappers to KVM's domain context_tracking: Consolidate guest enter/exit wrappers sched/vtime: Move guest enter/exit vtime accounting to vtime.h sched/vtime: Move vtime accounting external declarations above inlines KVM: x86: Defer vtime accounting 'til after IRQ handling context_tracking: Move guest exit vtime accounting to separate helpers context_tracking: Move guest exit context tracking to separate helpers KVM/VMX: Invoke NMI non-IST entry instead of IST entry x86/cpu: Remove write_tsc() and write_rdtscp_aux() wrappers x86/cpu: Initialize MSR_TSC_AUX if RDTSCP *or* RDPID is supported x86/resctrl: Fix init const confusion x86: Delete UD0, UD1 traces x86/smpboot: Remove duplicate includes x86/cpu: Use alternative to generate the TASK_SIZE_MAX constant -
Jens Axboe authored
This reverts commit cd2c7545. Alex reports that the commit causes corruption with LUKS on ext4. Revert it for now so that this can be investigated properly. Link: https://lore.kernel.org/linux-block/1620493841.bxdq8r5haw.none@localhost/Reported-by:
Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- 08 May, 2021 8 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
Pull RISC-V fixes from Palmer Dabbelt: - A fix to avoid over-allocating the kernel's mapping on !MMU systems, which could lead to up to 2MiB of lost memory - The SiFive address extension errata only manifest on rv64, they are now disabled on rv32 where they are unnecessary - A pair of late-landing cleanups * tag 'riscv-for-linus-5.13-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: remove unused handle_exception symbol riscv: Consistify protect_kernel_linear_mapping_text_rodata() use riscv: enable SiFive errata CIP-453 and CIP-1200 Kconfig only if CONFIG_64BIT=y riscv: Only extend kernel reservation if mapped read-only
-
Linus Torvalds authored
intel_dp_check_mst_status() uses a 14-byte array to read the DPRX Event Status Indicator data, but then passes that buffer at offset 10 off as an argument to drm_dp_channel_eq_ok(). End result: there are only 4 bytes remaining of the buffer, yet drm_dp_channel_eq_ok() wants a 6-byte buffer. gcc-11 correctly warns about this case: drivers/gpu/drm/i915/display/intel_dp.c: In function ‘intel_dp_check_mst_status’: drivers/gpu/drm/i915/display/intel_dp.c:3491:22: warning: ‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4 [-Wstringop-overread] 3491 | !drm_dp_channel_eq_ok(&esi[10], intel_dp->lane_count)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/display/intel_dp.c:3491:22: note: referencing argument 1 of type ‘const u8 *’ {aka ‘const unsigned char *’} In file included from drivers/gpu/drm/i915/display/intel_dp.c:38: include/drm/drm_dp_helper.h:1466:6: note: in a call to function ‘drm_dp_channel_eq_ok’ 1466 | bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE], | ^~~~~~~~~~~~~~~~~~~~ 6:14 elapsed This commit just extends the original array by 2 zero-initialized bytes, avoiding the warning. There may be some underlying bug in here that caused this confusion, but this is at least no worse than the existing situation that could use random data off the stack. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull more SCSI updates from James Bottomley: "This is a set of minor fixes in various drivers (qla2xxx, ufs, scsi_debug, lpfc) one doc fix and a fairly large update to the fnic driver to remove the open coded iteration functions in favour of the scsi provided ones" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: fnic: Use scsi_host_busy_iter() to traverse commands scsi: fnic: Kill 'exclude_id' argument to fnic_cleanup_io() scsi: scsi_debug: Fix cmd_per_lun, set to max_queue scsi: ufs: core: Narrow down fast path in system suspend path scsi: ufs: core: Cancel rpm_dev_flush_recheck_work during system suspend scsi: ufs: core: Do not put UFS power into LPM if link is broken scsi: qla2xxx: Prevent PRLI in target mode scsi: qla2xxx: Add marginal path handling support scsi: target: tcmu: Return from tcmu_handle_completions() if cmd_id not found scsi: ufs: core: Fix a typo in ufs-sysfs.c scsi: lpfc: Fix bad memory access during VPD DUMP mailbox command scsi: lpfc: Fix DMA virtual address ptr assignment in bsg scsi: lpfc: Fix illegal memory access on Abort IOCBs scsi: blk-mq: Fix build warning when making htmldocs
-
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuildLinus Torvalds authored
Pull more Kbuild updates from Masahiro Yamada: - Convert sh and sparc to use generic shell scripts to generate the syscall headers - refactor .gitignore files - Update kernel/config_data.gz only when the content of the .config is really changed, which avoids the unneeded re-link of vmlinux - move "remove stale files" workarounds to scripts/remove-stale-files - suppress unused-but-set-variable warnings by default for Clang as well - fix locale setting LANG=C to LC_ALL=C - improve 'make distclean' - always keep intermediate objects from scripts/link-vmlinux.sh - move IF_ENABLED out of <linux/kconfig.h> to make it self-contained - misc cleanups * tag 'kbuild-v5.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (25 commits) linux/kconfig.h: replace IF_ENABLED() with PTR_IF() in <linux/kernel.h> kbuild: Don't remove link-vmlinux temporary files on exit/signal kbuild: remove the unneeded comments for external module builds kbuild: make distclean remove tag files in sub-directories kbuild: make distclean work against $(objtree) instead of $(srctree) kbuild: refactor modname-multi by using suffix-search kbuild: refactor fdtoverlay rule kbuild: parameterize the .o part of suffix-search arch: use cross_compiling to check whether it is a cross build or not kbuild: remove ARCH=sh64 support from top Makefile .gitignore: prefix local generated files with a slash kbuild: replace LANG=C with LC_ALL=C Makefile: Move -Wno-unused-but-set-variable out of GCC only block kbuild: add a script to remove stale generated files kbuild: update config_data.gz only when the content of .config is changed .gitignore: ignore only top-level modules.builtin .gitignore: move tags and TAGS close to other tag files kernel/.gitgnore: remove stale timeconst.h and hz.bc usr/include: refactor .gitignore genksyms: fix stale comment ...
-
Steve French authored
Mounting with "multichannel" is obviously implied if user requested more than one channel on mount (ie mount parm max_channels>1). Currently both have to be specified. Fix that so that if max_channels is greater than 1 on mount, enable multichannel rather than silently falling back to non-multichannel. Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-By:
Tom Talpey <tom@talpey.com> Cc: <stable@vger.kernel.org> # v5.11+ Reviewed-by:
Shyam Prasad N <sprasad@microsoft.com>
-
Steve French authored
We were ignoring CAP_MULTI_CHANNEL in the server response - if the server doesn't support multichannel we should not be attempting it. See MS-SMB2 section 3.2.5.2 Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc updates and fixes from Michael Ellerman: "A bit of a mixture of things, tying up some loose ends. There's the removal of the nvlink code, which dependend on a commit in the vfio tree. Then the enablement of huge vmalloc which was in next for a few weeks but got dropped due to conflicts. And there's also a few fixes. Summary: - Remove the nvlink support now that it's only user has been removed. - Enable huge vmalloc mappings for Radix MMU (P9). - Fix KVM conversion to gfn-based MMU notifier callbacks. - Fix a kexec/kdump crash with hot plugged CPUs. - Fix boot failure on 32-bit with CONFIG_STACKPROTECTOR. - Restore alphabetic order of the selects under CONFIG_PPC. Thanks to: Christophe Leroy, Christoph Hellwig, Nicholas Piggin, Sandipan Das, and Sourabh Jain" * tag 'powerpc-5.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: KVM: PPC: Book3S HV: Fix conversion to gfn-based MMU notifier callbacks powerpc/kconfig: Restore alphabetic order of the selects under CONFIG_PPC powerpc/32: Fix boot failure with CONFIG_STACKPROTECTOR powerpc/powernv/memtrace: Fix dcache flushing powerpc/kexec_file: Use current CPU info while setting up FDT powerpc/64s/radix: Enable huge vmalloc mappings powerpc/powernv: remove the nvlink support
-
Steve French authored
In the SMB3/SMB3.1.1 negotiate protocol request, we are supposed to advertise CAP_MULTICHANNEL capability when establishing multiple channels has been requested by the user doing the mount. See MS-SMB2 sections 2.2.3 and 3.2.5.2 Without setting it there is some risk that multichannel could fail if the server interpreted the field strictly. Reviewed-By:
-
