- 16 Sep, 2022 20 commits
-
-
Serge Semin authored
There is no point in reading the AHCI version all over in the tail of the ahci_save_initial_config() method. That register is RO and doesn't change its value even after reset. So just reuse the data, which has already been read from there earlier in the head of the function. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com>
-
Serge Semin authored
Currently there are four port-map-related fields declared in the ahci_host_priv structure and used to setup the HBA ports mapping. First the ports-mapping is read from the PI register and immediately stored in the saved_port_map field. If forced_port_map is initialized with non-zero value then its value will have greater priority over the value read from PI, thus it will override the saved_port_map field. That value will be then masked by a non-zero mask_port_map field and after some sanity checks it will be stored in the ahci_host_priv.port_map field as a final port mapping. As you can see the logic is a bit too complicated for such a simple task. We can freely get rid from at least one of the fields with no change to the implemented semantic. The force_port_map field can be replaced with taking non-zero saved_port_map value into account. So if saved_port_map is pre-initialized by the low level drivers (platform drivers) then it will have greater priority over the value read from PI register and will be used as actual HBA ports mapping later on. Thus the ports map forcing task will be just transferred from force_port_map to the saved_port_map field. This modification will perfectly fit into the feature of having OF-based initialization of the HW-init HBA CSR fields we are about to introduce in the next commit. Signed-off-by:
-
Serge Semin authored
Currently not all of the Port-specific capabilities listed in the PORT_CMD-enumeration. Let's extend that set with the Cold Presence Detection and Mechanical Presence Switch attached to the Port flags [1] so to closeup the set of the platform-specific port-capabilities flags. Note these flags are supposed to be set by the platform firmware if there is one. Alternatively as we are about to do they can be set by means of the OF properties. While at it replace PORT_IRQ_DEV_ILCK with PORT_IRQ_DMPS and fix the comment there. In accordance with [2] that IRQ flag is supposed to indicate the state of the signal coming from the Mechanical Presence Switch. [1] Serial ATA AHCI 1.3.1 Specification, p.27 [2] Serial ATA AHCI 1.3.1 Specification, p.24, p.88 Signed-off-by:
-
Serge Semin authored
In case if the platform doesn't have BIOS or a comprehensive firmware installed then the HBA capability flags will be left uninitialized. As a good alternative we suggest to define the DT-properties with the AHCI platform capabilities describing all the HW-init flags of the corresponding capability register. Luckily there aren't too many of them. SSS - Staggered Spin-up support and MPS - Mechanical Presence Switch support determine the corresponding feature availability for the whole HBA by means of the "hba-cap" property. Each port can have the "hba-port-cap" property initialized indicating that the port supports some of the next functionalities: HPCP - HotPlug capable port, MPSP - Mechanical Presence Switch attached to a port, CPD - Cold Plug detection, ESP - External SATA Port (eSATA), FBSCP - FIS-based switching capable port. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Serge Semin authored
Currently the ACHI-platform library supports only the assert and deassert reset signals and ignores the platforms with self-deasserting reset lines. That prone to having the platforms with self-deasserting reset method misbehaviour when it comes to resuming from sleep state after the clocks have been fully disabled. For such cases the controller needs to be fully reset all over after the reference clocks are enabled and stable, otherwise the controller state machine might be in an undetermined state. The best solution would be to auto-detect which reset method is supported by the particular platform and use it implicitly in the framework of the ahci_platform_enable_resources()/ahci_platform_disable_resources() methods. Alas it can't be implemented due to the AHCI-platform library already supporting the shared reset control lines. As [1] says in such case we have to use only one of the next methods: + reset_control_assert()/reset_control_deassert(); + reset_control_reset()/reset_control_rearm(). If the driver had an exclusive control over the reset lines we could have been able to manipulate the lines with no much limitation and just used the combination of the methods above to cover all the possible reset-control cases. Since the shared reset control has already been advertised and couldn't be changed with no risk to breaking the platforms relying on it, we have no choice but to make the platform drivers to determine which reset methods the platform reset system supports. In order to implement both types of reset control support we suggest to introduce the new AHCI-platform flag: AHCI_PLATFORM_RST_TRIGGER, which when passed to the ahci_platform_get_resources() method together with the AHCI_PLATFORM_GET_RESETS flag will indicate that the reset lines are self-deasserting thus the reset_control_reset()/reset_control_rearm() will be used to control the reset state. Otherwise the reset_control_deassert()/reset_control_assert() methods will be utilized. [1] Documentation/driver-api/reset.rst Signed-off-by:
-
Serge Semin authored
The ports-implemented property is mainly used on the OF-based platforms with no ports mapping initialized by a bootloader/BIOS firmware. Seeing the same of_property_read_u32()-based pattern has already been implemented in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI drivers let's move the property read procedure to the generic ahci_platform_get_resources() method. Thus we'll have the forced ports mapping feature supported for each OF-based platform which requires that, and stop re-implementing the same pattern in there a bit simplifying the code. Signed-off-by:
-
Serge Semin authored
Having greater than AHCI_MAX_PORTS (32) ports detected isn't that critical from the further AHCI-platform initialization point of view since exceeding the ports upper limit will cause allocating more resources than will be used afterwards. But detecting too many child DT-nodes doesn't seem right since it's very unlikely to have it on an ordinary platform. In accordance with the AHCI specification there can't be more than 32 ports implemented at least due to having the CAP.NP field of 5 bits wide and the PI register of dword size. Thus if such situation is found the DTB must have been corrupted and the data read from it shouldn't be reliable. Let's consider that as an erroneous situation and halt further resources allocation. Note it's logically more correct to have the nports set only after the initialization value is checked for being sane. So while at it let's make sure nports is assigned with a correct value. Signed-off-by:
-
Serge Semin authored
In order to simplify the clock-related code there is a way to convert the current fixed clocks array into using the common bulk clocks kernel API with dynamic set of the clock handlers and device-managed clock-resource tracking. It's a bit tricky due to the complication coming from the requirement to support the platforms (da850, spear13xx) with the non-OF-based clock source, but still doable. Before this modification there are two methods have been used to get the clocks connected to an AHCI device: clk_get() - to get the very first clock in the list and of_clk_get() - to get the rest of them. Basically the platforms with non-OF-based clocks definition could specify only a single reference clock source. The platforms with OF-hw clocks have been luckier and could setup up to AHCI_MAX_CLKS clocks. Such semantic can be retained with using devm_clk_bulk_get_all() to retrieve the clocks defined via the DT firmware and devm_clk_get_optional() otherwise. In both cases using the device-managed version of the methods will cause the automatic resources deallocation on the AHCI device removal event. The only complicated part in the suggested approach is the explicit allocation and initialization of the clk_bulk_data structure instance for the non-OF reference clocks. It's required in order to use the Bulk Clocks API for the both denoted cases of the clocks definition. Note aside with the clock-related code reduction and natural simplification, there are several bonuses the suggested modification provides. First of all the limitation of having no greater than AHCI_MAX_CLKS clocks is now removed, since the devm_clk_bulk_get_all() method will allocate as many reference clocks data descriptors as there are clocks specified for the device. Secondly the clock names are auto-detected. So the LLDD (glue) drivers can make sure that the required clocks are specified just by checking the clock IDs in the clk_bulk_data array. Thirdly using the handy Bulk Clocks kernel API improves the clocks-handling code readability. And the last but not least this modification implements a true optional clocks support to the ahci_platform_get_resources() method. Indeed the previous clocks getting procedure just stopped getting the clocks on any errors (aside from non-critical -EPROBE_DEFER) in a way so the callee wasn't even informed about abnormal loop termination. The new implementation lacks of such problem. The ahci_platform_get_resources() will return an error code if the corresponding clocks getting method ends execution abnormally. Signed-off-by:
-
Serge Semin authored
Currently the IOMEM AHCI registers space is mapped by means of the two functions invocation: platform_get_resource() is used to get the very first memory resource and devm_ioremap_resource() is called to remap that resource. Device-managed kernel API provides a handy wrapper to perform the same in single function call: devm_platform_ioremap_resource(). While at it seeing many AHCI platform drivers rely on having the AHCI CSR space marked with "ahci" name let's first try to find and remap the CSR IO-mem with that name and only if it fails fallback to getting the very first registers space platform resource. Signed-off-by:
-
Serge Semin authored
The Broadcom SATA controller is obviously based on the AHCI standard. The device driver uses the kernel AHCI library to work with it. Therefore we can be have a more thorough DT-bindings evaluation by referring to the AHCI-common schema instead of using the more relaxed SATA-common one. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
-
Serge Semin authored
The denoted in the description upper limit only concerns the Port Multipliers, but not the actual SATA ports. It's an external device attached to a SATA port in order to access more than one SATA-drive. So when it's attached to a SATA port it just extends the port capability while the number of actual SATA ports stays the same. For instance on AHCI controllers the number of actual ports is determined by the CAP.NP field and the PI (Ports Implemented) register. AFAICS in general the maximum number of SATA ports depends on the particular controller implementation. Generic AHCI controller can't have more than 32 ports (since CAP.NP is of 5 bits wide and PI register is 32-bits size), while DWC AHCI SATA controller can't be configured with more than 8 ports activated. So let's discard the SATA ports reg-property restrictions and just make sure that it consists of a single reg-item. Signed-off-by:
-
Serge Semin authored
Indeed in accordance with what is implemented in the AHCI platform driver and the way the AHCI DT nodes are defined in the DT files we can add the next AHCI DT properties constraints: AHCI CSR ID is fixed to 'ahci', PHY name is fixed to 'sata-phy', AHCI controller can't have more than 32 ports by design, AHCI controller can have up to 32 IRQ lines. Signed-off-by:
-
Serge Semin authored
In order to create a more sophisticated AHCI controller DT bindings let's divide the already available generic AHCI platform YAML schema into the platform part and a set of the common AHCI properties. The former part will be used to evaluate the AHCI DT nodes mainly compatible with the generic AHCI controller while the later schema will be used for more thorough AHCI DT nodes description. For instance such YAML schemas design will be useful for our DW AHCI SATA controller derivative with four clock sources, two reset lines, one system controller reference and specific max Rx/Tx DMA xfers size constraints. Note the phys and target-supply property requirement is preserved in the generic AHCI platform bindings because some platforms can lack of the explicitly specified PHYs or target device power regulators. Also note the SATA/AHCI ports properties have been moved to the $defs-paragraph of the schemas. It's done in order to create the extendable properties hierarchy such that particular AHCI-controller could add vendor-specific port properties. Signed-off-by:
-
Serge Semin authored
Seeing doubtfully any SATA device working without embedded DMA engine let's permit the device nodes being equipped with the dma-coherent property in case if the platform is capable of cache-coherent DMAs. As a side-effect we can drop the explicit dma-coherent property definition from the particular device schemas. Currently it concerns the Broadcom SATA AHCI controller only. Signed-off-by:
-
Lukas Bulwahn authored
It is currently possible to select "Generic platform device PATA support" in two situations: - architecture allows the generic platform device PATA support and indicates that with "select HAVE_PATA_PLATFORM". - if the user claims to be an EXPERT by setting CONFIG_EXPERT to yes However, there is no use case to have Generic platform device PATA support in a kernel build if the architecture definition, i.e., the selection of configs by an architecture, does not support it. If the architecture definition is wrong, i.e., it just misses a 'select HAVE_PATA_PLATFORM', then even an expert that configures the kernel build should not just fix that by overruling the claimed support by an architecture. If the architecture definition is wrong, the expert should just provide a patch to correct the architecture definition instead---in the end, if the user is an expert, sending a quick one-line patch should not be an issue. In other words, I do not see the deeper why an expert can overrule the architecture definition in this case, as the expert may not overrule the config selections defined by the architecture in the large majority ---or probably all other (modulo some mistakes)---of similar cases. Signed-off-by:Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Lukas Bulwahn authored
There are two options for platform device PATA support: PATA_PLATFORM: Generic platform device PATA support PATA_OF_PLATFORM: OpenFirmware platform device PATA support If an architecture allows the generic platform device PATA support, it shall select HAVE_PATA_PLATFORM. Then, Generic platform device PATA support is available and can be selected. If an architecture has OpenFirmware support, which it indicates by selecting OF, OpenFirmware platform device PATA support is available and can be selected. If OpenFirmware platform device PATA support is selected, then the functionality (code files) from Generic platform device PATA support needs to be integrated in the kernel build for the OpenFirmware platform device PATA support to work. Select PATA_PLATFORM in PATA_OF_PLATFORM to make sure the needed files are added in the build. So, architectures with OpenFirmware support, do not need to additionally select HAVE_PATA_PLATFORM. It is only needed by architecture that want the non-OF pata-platform module. Reflect this way of intended use of config symbols in the ata Kconfig and adjust all architecture definitions. This follows the suggestion from Arnd Bergmann (see Link). Suggested-by:
-
Li Zhong authored
sata_scr_read() could return negative error code on failure. Check the return value when reading the control register. Signed-off-by:
Li Zhong <floridsleeves@gmail.com> Signed-off-by:
-
Shaomin Deng authored
Remove the repeated word "Transfer" in comments. Signed-off-by:
Shaomin Deng <dengshaomin@cdjrlc.com> Signed-off-by:
-
Shaomin Deng authored
There is unneeded word "to" in line 669, so remove it. Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by:
-
Damien Le Moal authored
The err_mask variable is not useful. Remove it. Signed-off-by:
-
- 25 Aug, 2022 4 commits
-
-
Damien Le Moal authored
Since ata_build_rw_tf() is only called from ata_scsi_rw_xlat() with the tf, dev and tag arguments obtained from the queued command structure, we can simplify the interface of ata_build_rw_tf() by passing directly the qc structure as argument. Furthermore, since ata_scsi_rw_xlat() is never used for internal commands, we can also remove the internal tag check for the NCQ case. Signed-off-by: -
Damien Le Moal authored
Rename ATA_DFLAG_NCQ_PRIO_ENABLE to ATA_DFLAG_NCQ_PRIO_ENABLED to match the fact that this flags indicates if NCQ priority use is enabled by the user. Signed-off-by: -
Jinpeng Cui authored
Return value from ata_exec_internal() directly instead of taking this in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Jinpeng Cui <cui.jinpeng2@zte.com.cn> Signed-off-by:
-
Rafael J. Wysocki authored
The ACPI_FADT_LOW_POWER_S0 flag merely means that it is better to use low-power S0 idle on the given platform than S3 (provided that the latter is supported) and it doesn't preclude using either of them (which of them will be used depends on the choices made by user space). For this reason, there is no benefit from checking that flag in ahci_update_initial_lpm_policy(). First off, it cannot be a bug to do S3 with policy set to either ATA_LPM_MIN_POWER_WITH_PARTIAL or ATA_LPM_MIN_POWER, because S3 can be used on systems with ACPI_FADT_LOW_POWER_S0 set and it must work if really supported, so the ACPI_FADT_LOW_POWER_S0 check is not needed to protect the S3-capable systems from failing. Second, suspend-to-idle can be carried out on a system with ACPI_FADT_LOW_POWER_S0 unset and it is expected to work, so if setting policy to either ATA_LPM_MIN_POWER_WITH_PARTIAL or ATA_LPM_MIN_POWER is needed to handle that case correctly, it should be done regardless of the ACPI_FADT_LOW_POWER_S0 value. Accordingly, replace the ACPI_FADT_LOW_POWER_S0 check in ahci_update_initial_lpm_policy() with pm_suspend_default_s2idle() which is more general and also takes the user's preference into account and drop the CONFIG_ACPI #ifdef around it that is not necessary any more. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
- 17 Aug, 2022 2 commits
-
-
Niklas Cassel authored
ata_dev_set_feature() is currently used for enabling/disabling any ATA feature, e.g. SETFEATURES_SPINUP and SETFEATURE_SENSE_DATA, i.e. it is not only used to enable/disable SATA specific features. For most features, the enable/disable bit is specified in the subcommand specific field "count". It is only for the specific subcommands "Enable SATA feature" (0x10) and "Disable SATA feature" (0x90) where the field "count" is used to specify a feature instead of enable/disable. The parameter names for this function are thus quite misleading. Rename the parameter names to be more generic and in line with ACS-5, and remove the references to "SATA FEATURES" in the kernel-doc. Signed-off-by:
Niklas Cassel <niklas.cassel@wdc.com> Signed-off-by:
-
Tomas Henzl authored
Printing the timeout value may help in troubleshooting failures. Signed-off-by:
David Milburn <dmilburn@redhat.com> Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
- 14 Aug, 2022 10 commits
-
-
Linus Torvalds authored
-
Yury Norov authored
Radix tree header includes gfp.h for __GFP_BITS_SHIFT only. Now we have gfp_types.h for this. Fixes powerpc allmodconfig build: In file included from include/linux/nodemask.h:97, from include/linux/mmzone.h:17, from include/linux/gfp.h:7, from include/linux/radix-tree.h:12, from include/linux/idr.h:15, from include/linux/kernfs.h:12, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/pci.h:35, from arch/powerpc/kernel/prom_init.c:24: include/linux/random.h: In function 'add_latent_entropy': >> include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'? 25 | add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy)); | ^~~~~~~~~~~~~~ | add_latent_entropy include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in Reported-by:kernel test robot <lkp@intel.com> CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Yury Norov <yury.norov@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs lseek fix from Al Viro: "Fix proc_reg_llseek() breakage. Always had been possible if somebody left NULL ->proc_lseek, became a practical issue now" * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: take care to handle NULL ->proc_lseek()
-
Al Viro authored
Easily done now, just by clearing FMODE_LSEEK in ->f_mode during proc_reg_open() for such entries. Fixes: 868941b1 "fs: remove no_llseek" Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds authored
Pull more xen updates from Juergen Gross: - fix the handling of the "persistent grants" feature negotiation between Xen blkfront and Xen blkback drivers - a cleanup of xen.config and adding xen.config to Xen section in MAINTAINERS - support HVMOP_set_evtchn_upcall_vector, which is more compliant to "normal" interrupt handling than the global callback used up to now - further small cleanups * tag 'for-linus-6.0-rc1b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: MAINTAINERS: add xen config fragments to XEN HYPERVISOR sections xen: remove XEN_SCRUB_PAGES in xen.config xen/pciback: Fix comment typo xen/xenbus: fix return type in xenbus_file_read() xen-blkfront: Apply 'feature_persistent' parameter when connect xen-blkback: Apply 'feature_persistent' parameter when connect xen-blkback: fix persistent grants negotiation x86/xen: Add support for HVMOP_set_evtchn_upcall_vector
-
Linus Torvalds authored
Merge tag 'perf-tools-fixes-for-v6.0-2022-08-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull more perf tool updates from Arnaldo Carvalho de Melo: - 'perf c2c' now supports ARM64, adjust its output to cope with differences with what is in x86_64. Now go find false sharing on ARM64 (at least Neoverse) as well! - Refactor the JSON processing, making the output more compact and thus reducing the size of the resulting perf binary - Improvements for 'perf offcpu' profiling, including tracking child processes - Update Intel JSON metrics and events files for broadwellde, broadwellx, cascadelakex, haswellx, icelakex, ivytown, jaketown, knightslanding, sapphirerapids, skylakex and snowridgex - Add 'perf stat' JSON output and a 'perf test' entry for it - Ignore memfd and anonymous mmap events if jitdump present - Refactor 'perf test' shell tests allowing subdirs - Fix an error handling path in 'parse_perf_probe_command()' - Fixes for the guest Intel PT tracing patchkit in the 1st batch of this merge window - Print debuginfod queries if -v option is used, to explain delays in processing when debuginfo servers are enabled to fetch DSOs with richer symbol tables - Improve error message for 'perf record -p not_existing_pid' - Fix openssl and libbpf feature detection - Add PMU pai_crypto event description for IBM z16 on 'perf list' - Fix typos and duplicated words on comments in various places * tag 'perf-tools-fixes-for-v6.0-2022-08-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (81 commits) perf test: Refactor shell tests allowing subdirs perf vendor events: Update events for snowridgex perf vendor events: Update events and metrics for skylakex perf vendor events: Update metrics for sapphirerapids perf vendor events: Update events for knightslanding perf vendor events: Update metrics for jaketown perf vendor events: Update metrics for ivytown perf vendor events: Update events and metrics for icelakex perf vendor events: Update events and metrics for haswellx perf vendor events: Update events and metrics for cascadelakex perf vendor events: Update events and metrics for broadwellx perf vendor events: Update metrics for broadwellde perf jevents: Fold strings optimization perf jevents: Compress the pmu_events_table perf metrics: Copy entire pmu_event in find metric perf pmu-events: Hide the pmu_events perf pmu-events: Don't assume pmu_event is an array perf pmu-events: Move test events/metrics to JSON perf test: Use full metric resolution perf pmu-events: Hide pmu_events_map ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - Ensure we never emit lwarx with EH=1 on 32-bit, because some 32-bit CPUs trap on it rather than ignoring it as they should. - Fix ftrace when building with clang, which was broken by some refactoring. - A couple of other minor fixes. Thanks to Christophe Leroy, Naveen N. Rao, Nick Desaulniers, Ondrej Mosnacek, Pali Rohár, Russell Currey, and Segher Boessenkool. * tag 'powerpc-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/kexec: Fix build failure from uninitialised variable powerpc/ppc-opcode: Fix PPC_RAW_TW() powerpc64/ftrace: Fix ftrace for clang builds powerpc: Make eh value more explicit when using lwarx powerpc: Don't hide eh field of lwarx behind a macro powerpc: Fix eh field when calling lwarx on PPC32
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull /proc/mounts fix from Al Viro: "Fix for /proc/mounts escaping - escape the '#' character too" * tag 'pull-work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: vfs: escape hash as well
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull more cifs updates from Steve French: - two fixes for stable, one for a lock length miscalculation, and another fixes a lease break timeout bug - improvement to handle leases, allows the close timeout to be configured more safely - five restructuring/cleanup patches * tag '5.20-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6: cifs: Do not access tcon->cfids->cfid directly from is_path_accessible cifs: Add constructor/destructors for tcon->cfid SMB3: fix lease break timeout when multiple deferred close handles for the same file. smb3: allow deferred close timeout to be configurable cifs: Do not use tcon->cfid directly, use the cfid we get from open_cached_dir cifs: Move cached-dir functions into a separate file cifs: Remove {cifs,nfs}_fscache_release_page() cifs: fix lock length calculation
-
David Howells authored
Enable multipage folio support for the afs filesystem. Support has already been implemented in netfslib, fscache and cachefiles and in most of afs, but I've waited for Matthew Wilcox's latest folio changes. Note that it does require a change to afs_write_begin() to return the correct subpage. This is a "temporary" change as we're working on getting rid of the need for ->write_begin() and ->write_end() completely, at least as far as network filesystems are concerned - but it doesn't prevent afs from making use of the capability. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Tested-by: kafs-testing@auristor.com Cc: Marc Dionne <marc.dionne@auristor.com> Cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/lkml/2274528.1645833226@warthog.procyon.org.uk/Signed-off-by:
-
- 13 Aug, 2022 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Ingo Molnar: "Misc timer fixes: - fix a potential use-after-free bug in posix timers - correct a prototype - address a build warning" * tag 'timers-urgent-2022-08-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: posix-cpu-timers: Cleanup CPU timers before freeing them during exec time: Correct the prototype of ns_to_kernel_old_timeval and ns_to_timespec64 posix-timers: Make do_clock_gettime() static
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fix from Ingo Molnar: "Fix the 'IBPB mitigated RETBleed' mode of operation on AMD CPUs (not turned on by default), which also need STIBP enabled (if available) to be '100% safe' on even the shortest speculation windows" * tag 'x86-urgent-2022-08-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/bugs: Enable STIBP for IBPB mitigated RETBleed
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull more i2c updates from Wolfram Sang: - two driver fixes for issues introduced this cycle - one trivial driver improvement regarding ACPI - more DTS conversion and additions - documentation updates - subsystem-wide move from strlcpy to strscpy * tag 'i2c-for-5.20-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: docs: i2c: i2c-sysfs: fix hyperlinks docs: i2c: i2c-sysfs: improve wording docs: i2c: instantiating-devices: add syntax coloring to dts and C blocks docs: i2c: smbus-protocol: improve DataLow/DataHigh definition docs: i2c: i2c-protocol: remove unused legend items docs: i2c: i2c-protocol,smbus-protocol: remove nonsense words docs: i2c: i2c-protocol: update introductory paragraph i2c: move core from strlcpy to strscpy i2c: move drivers from strlcpy to strscpy i2c: kempld: Support ACPI I2C device declaration i2c: mediatek: add i2c compatible for MT8188 dt-bindings: i2c: update bindings for mt8188 soc i2c: microchip-corei2c: fix erroneous late ack send dt-bindings: i2c: qcom,i2c-cci: convert to dtschema i2c: qcom-geni: Fix GPI DMA buffer sync-back
-
https://github.com/jonmason/ntbLinus Torvalds authored
Pull NTB updates from Jon Mason: "Non-Transparent Bridge updates. Fix of heap data and clang warnings, support for a new Intel NTB device, and NTB EndPoint Function (EPF) support and the various fixes for that" * tag 'ntb-5.20' of https://github.com/jonmason/ntb: MAINTAINERS: add PCI Endpoint NTB drivers to NTB files NTB: EPF: Tidy up some bounds checks NTB: EPF: Fix error code in epf_ntb_bind() PCI: endpoint: pci-epf-vntb: reduce several globals to statics PCI: endpoint: pci-epf-vntb: fix error handle in epf_ntb_mw_bar_init() PCI: endpoint: Fix Kconfig dependency NTB: EPF: set pointer addr to null using NULL rather than 0 Documentation: PCI: extend subheading underline for "lspci output" section Documentation: PCI: Use code-block block for scratchpad registers diagram Documentation: PCI: Add specification for the PCI vNTB function device PCI: endpoint: Support NTB transfer between RC and EP NTB: epf: Allow more flexibility in the memory BAR map method PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address ntb: intel: add GNR support for Intel PCIe gen5 NTB NTB: ntb_tool: uninitialized heap data in tool_fn_write() ntb: idt: fix clang -Wformat warnings
-
