summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-28hwmon: (max31827) handle vref regulatorAntoniu Miclaus
Add missing implementation for the max31827 supply regulator. This is a hardware required property that is not handled. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://lore.kernel.org/r/20230925122929.10610-1-antoniu.miclaus@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (ina3221) Add support for channel summation disableNinad Malwade
The INA3221 allows the Critical alert pin to be controlled by the summation control function. This function adds the single shunt-voltage conversions for the desired channels in order to compare the combined sum to the programmed limit. The Shunt-Voltage Sum Limit register contains the programmed value that is compared to the value in the Shunt-Voltage Sum register in order to determine if the total summed limit is exceeded. If the shunt-voltage sum limit value is exceeded, the Critical alert pin pulls low. For the summation limit to have a meaningful value, we have to use the same shunt-resistor value on all included channels. Unless equal shunt-resistor values are used for each channel, the summation control function cannot be used and it is not enabled by the driver. To address this, add support to disable the summation of specific channels via device tree property "ti,summation-disable". The channel which has this property would be excluded from the calculation of summation control function. For example, summation control function calculates Shunt-Voltage Sum as: - input_shunt_voltage_summation = input_shunt_voltage_channel1 + input_shunt_voltage_channel2 + input_shunt_voltage_channel3 If we want the summation to only use channel1 and channel3, we can add 'ti,summation-disable' property in device tree node for channel2. Then the calculation will skip channel2. - input_shunt_voltage_summation = input_shunt_voltage_channel1 + input_shunt_voltage_channel3 Note that we only want the channel to be skipped for summation control function rather than completely disabled. Therefore, even if we add the property 'ti,summation-disable', the channel is still enabled and functional. Finally, create debugfs entries that display if summation is disabled for each of the channels. Signed-off-by: Rajkumar Kasirajan <rkasirajan@nvidia.com> Signed-off-by: Ninad Malwade <nmalwade@nvidia.com> Co-developed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20230929103650.86074-4-jonathanh@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28dt-bindings: hwmon: ina3221: Add ti,summation-disableJon Hunter
The INA3221 has a critical alert pin that can be controlled by the summation control function. This function adds the single shunt-voltage conversions for the desired channels in order to compare the combined sum to the programmed limit. The Shunt-Voltage Sum Limit register contains the programmed value that is compared to the value in the Shunt-Voltage Sum register in order to determine if the total summed limit is exceeded. If the shunt-voltage sum limit value is exceeded, the critical alert pin pulls low. For the summation limit to have a meaningful value, it is necessary to use the same shunt-resistor value on all included channels. Add a new vendor specific property, 'ti,summation-disable', to allow specific channels to be excluded from the summation control function if the shunt resistor is different to other channels or the channel should not be considered for triggering the critical alert pin. Note that the ina3221 has always supported summing the various input channels and summation is enabled by default if the shunt-resistor values are the same. This change simply provides a way to exclude inputs from the summation. If this property is not populated, then the functionality of the driver does not change. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Ninad Malwade <nmalwade@nvidia.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230929103650.86074-3-jonathanh@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28dt-bindings: hwmon: ina3221: Convert to json-schemaNinad Malwade
Convert the TI INA3221 bindings from the free-form text format to json-schema. Note that the INA3221 input channels default to enabled in the chip. Unless channels are explicitly disabled in device-tree, input channels will be enabled. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ninad Malwade <nmalwade@nvidia.com> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230929103650.86074-2-jonathanh@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (pmbus/mpq7932) Add a support for mpq2286 Power Management ICSaravanan Sekar
The MPQ2286 is a programmable, high frequency synchronous buck regulator designed to power a variety of Automotive system peripherals. Single buck converters with hardware monitoring capability is configurable over PMBus interface. Signed-off-by: Saravanan Sekar <saravanan@linumiz.com> Link: https://lore.kernel.org/r/20231011164754.449399-5-saravanan@linumiz.com [groeck: Updated subject (mpq2286 -> mpq7932)] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (pmbus/core) Add helper macro to define single pmbus regulatorSaravanan Sekar
The bindings for single instance regulator should be named with no instance (e.g., buck not buck0). Introduce a new helper macro to define the single pmbus regulator. Signed-off-by: Saravanan Sekar <saravanan@linumiz.com> Link: https://lore.kernel.org/r/20231011164754.449399-4-saravanan@linumiz.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28regulator: dt-bindings: Add mps,mpq2286 power-management ICSaravanan Sekar
Document mpq2286 power-management IC. Signed-off-by: Saravanan Sekar <saravanan@linumiz.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231011164754.449399-3-saravanan@linumiz.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (pmbus/mpq7932) Get page count based on chip infoSaravanan Sekar
Get page count using compatible match to support the series of chipsets which differs in number of regualator/page. Signed-off-by: Saravanan Sekar <saravanan@linumiz.com> Link: https://lore.kernel.org/r/20231011164754.449399-2-saravanan@linumiz.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28dt-bindings: hwmon: Add possible new properties to max31827 bindingsDaniel Matyas
These modify the corresponding bits in the configuration register. adi,comp-int is a hardware property, because it affects the behavior of the interrupt signal and whatever it is connected to. adi,timeout-enable is a hardware property, because it affects i2c bus operation. Signed-off-by: Daniel Matyas <daniel.matyas@analog.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230919093456.10592-3-daniel.matyas@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (max31827) Modify conversion wait timeDaniel Matyas
There is nothing in the datasheet indicating that the 1ms error is needed and I didn't encounter any error during testing with 140ms wait time. Signed-off-by: Daniel Matyas <daniel.matyas@analog.com> Link: https://lore.kernel.org/r/20230919093456.10592-2-daniel.matyas@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (max31827) Make code cleanerDaniel Matyas
Used enums and while loops to replace switch for selecting and getting update interval from conversion rate bits. Divided the write_alarm_val function into 2 functions. The new function is more generic: it can be used not only for alarm writes, but for any kind of writes which require the device to be in shutdown mode. Signed-off-by: Daniel Matyas <daniel.matyas@analog.com> Link: https://lore.kernel.org/r/20230919093456.10592-1-daniel.matyas@analog.com [groeck: Reverted error return value change (EOPNOTSUPP -> EINVAL)] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28MAINTAINERS: Add Hal as one of the maintainers of SFCTEMP HWMON DRIVERHal Feng
As he is the submitter of this driver, add his mail so he can maintain the driver and easily reply in the mailing list. Acked-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Hal Feng <hal.feng@starfivetech.com> Link: https://lore.kernel.org/r/20230928075249.109459-1-hal.feng@starfivetech.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (nct6683) Add another customer ID for ASRock X670E TaichiAlexander Koskovich
This value was found on an ASRock X670E Taichi with an NCT6686D chip. Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Link: https://lore.kernel.org/r/20231023182442.21943-1-akoskovich@pm.me Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (ltc2992) Avoid division by zeroAntoniu Miclaus
Do not allow setting shunt resistor to 0. This results in a division by zero when performing current value computations based on input voltages and connected resistor values. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://lore.kernel.org/r/20231011135754.13508-1-antoniu.miclaus@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (npcm750-pwm) Add an error code check in npcm7xx_en_pwm_fanSu Hui
npcm7xx_pwm_config_set() can return '-ENODEV' for failed. So check the value of 'ret' after calling npcm7xx_pwm_config_set(). Signed-off-by: Su Hui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20231020085518.198477-1-suhui@nfschina.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (hs3001) remove redundant store on divisionColin Ian King
Currently the local variable hum is being divided by a constant and the results is being re-assigned back to hum before the value is being returned to the caller. The assignment to hum is redundant and can be removed. Cleans up clang scan build warning: drivers/hwmon/hs3001.c:65:9: warning: Although the value stored to 'hum' is used in the enclosing expression, the value is never actually read from 'hum' [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20231023135828.667297-1-colin.i.king@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28hwmon: (nct6775) use acpi_dev_hid_uid_match() for matching _HID and _UIDRaag Jadav
Convert manual _UID references to use the standard ACPI helper. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20231024062018.23839-6-raag.jadav@intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-28fs: fix build error with CONFIG_EXPORTFS=m or not definedAmir Goldstein
Many of the filesystems that call the generic exportfs helpers do not select the EXPORTFS config. Move generic_encode_ino32_fh() to libfs.c, same as generic_fh_to_*() to avoid having to fix all those config dependencies. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310262151.renqMvme-lkp@intel.com/ Fixes: dfaf653dc415 ("exportfs: make ->encode_fh() a mandatory method for NFS export") Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://lore.kernel.org/r/20231026204540.143217-1-amir73il@gmail.com Tested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28freevxfs: derive f_fsid from bdev->bd_devAmir Goldstein
The majority of blockdev filesystems, which do not have a UUID in their on-disk format, derive f_fsid of statfs(2) from bdev->bd_dev. Use the same practice for freevxfs. This will allow reporting fanotify events with fanotify_event_info_fid. Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://lore.kernel.org/r/20231024121457.3014063-1-amir73il@gmail.com Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28fs: report f_fsid from s_dev for "simple" filesystemsAmir Goldstein
There are many "simple" filesystems (*) that report null f_fsid in statfs(2). Those "simple" filesystems report sb->s_dev as the st_dev field of the stat syscalls for all inodes of the filesystem (**). In order to enable fanotify reporting of events with fsid on those "simple" filesystems, report the sb->s_dev number in f_fsid field of statfs(2). (*) For most of the "simple" filesystem refered to in this commit, the ->statfs() operation is simple_statfs(). Some of those fs assign the simple_statfs() method directly in their ->s_op struct and some assign it indirectly via a call to simple_fill_super() or to pseudo_fs_fill_super() with either custom or "simple" s_op. We also make the same change to efivarfs and hugetlbfs, although they do not use simple_statfs(), because they use the simple_* inode opreations (e.g. simple_lookup()). (**) For most of the "simple" filesystems, the ->getattr() method is not assigned, so stat() is implemented by generic_fillattr(). A few "simple" filesystem use the simple_getattr() method which also calls generic_fillattr() to fill most of the stat struct. The two exceptions are procfs and 9p. procfs implements several different ->getattr() methods, but they all end up calling generic_fillattr() to fill the st_dev field from sb->s_dev. 9p has more complicated ->getattr() methods, but they too, end up calling generic_fillattr() to fill the st_dev field from sb->s_dev. Note that 9p and kernfs also call simple_statfs() from custom ->statfs() methods which already fill the f_fsid field, but v9fs_statfs() calls simple_statfs() only in case f_fsid was not filled and kenrfs_statfs() overwrites f_fsid after calling simple_statfs(). Link: https://lore.kernel.org/r/20230919094820.g5bwharbmy2dq46w@quack3/ Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://lore.kernel.org/r/20231023143049.2944970-1-amir73il@gmail.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28exportfs: support encoding non-decodeable file handles by defaultAmir Goldstein
AT_HANDLE_FID was added as an API for name_to_handle_at() that request the encoding of a file id, which is not intended to be decoded. This file id is used by fanotify to describe objects in events. So far, overlayfs is the only filesystem that supports encoding non-decodeable file ids, by providing export_operations with an ->encode_fh() method and without a ->decode_fh() method. Add support for encoding non-decodeable file ids to all the filesystems that do not provide export_operations, by encoding a file id of type FILEID_INO64_GEN from { i_ino, i_generation }. A filesystem may that does not support NFS export, can opt-out of encoding non-decodeable file ids for fanotify by defining an empty export_operations struct (i.e. with a NULL ->encode_fh() method). This allows the use of fanotify events with file ids on filesystems like 9p which do not support NFS export to bring fanotify in feature parity with inotify on those filesystems. Note that fanotify also requires that the filesystems report a non-null fsid. Currently, many simple filesystems that have support for inotify (e.g. debugfs, tracefs, sysfs) report a null fsid, so can still not be used with fanotify in file id reporting mode. Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://lore.kernel.org/r/20231023180801.2953446-5-amir73il@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28exportfs: define FILEID_INO64_GEN* file handle typesAmir Goldstein
Similar to the common FILEID_INO32* file handle types, define common FILEID_INO64* file handle types. The type values of FILEID_INO64_GEN and FILEID_INO64_GEN_PARENT are the values returned by fuse and xfs for 64bit ino encoded file handle types. Note that these type value are filesystem specific and they do not define a universal file handle format, for example: fuse encodes FILEID_INO64_GEN as [ino-hi32,ino-lo32,gen] and xfs encodes FILEID_INO64_GEN as [hostr-order-ino64,gen] (a.k.a xfs_fid64). The FILEID_INO64_GEN fhandle type is going to be used for file ids for fanotify from filesystems that do not support NFS export. Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://lore.kernel.org/r/20231023180801.2953446-4-amir73il@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28exportfs: make ->encode_fh() a mandatory method for NFS exportAmir Goldstein
Rename the default helper for encoding FILEID_INO32_GEN* file handles to generic_encode_ino32_fh() and convert the filesystems that used the default implementation to use the generic helper explicitly. After this change, exportfs_encode_inode_fh() no longer has a default implementation to encode FILEID_INO32_GEN* file handles. This is a step towards allowing filesystems to encode non-decodeable file handles for fanotify without having to implement any export_operations. Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jeff Layton <jlayton@kernel.org> Acked-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://lore.kernel.org/r/20231023180801.2953446-3-amir73il@gmail.com Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28i2c: i801: Use new helper acpi_use_parent_companionHeiner Kallweit
Use new helper acpi_use_parent_companion to simplify the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-28ACPI: Add helper acpi_use_parent_companionHeiner Kallweit
In several drivers devices use the ACPI companion of the parent. Add a helper for this use case to avoid code duplication. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-28MAINTAINERS: add YAML file for i2c-demux-pinctrlWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-28i2c: core: fix lockdep warning for sparsely nested adapter chainDaniel Mack
When adapters are chained in a sparse manner (with intermediate MFD devices, for instance) the code currently fails to use the correct subclass for the adapter's bus_lock which leads to false-positive lockdep warnings. Fix this by walking the entire pedigree of the device and count all adapters along the way instead of just checking the immediate parent. Signed-off-by: Daniel Mack <daniel@zonque.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-28i2c: axxia: eliminate kernel-doc warningsRandy Dunlap
Add kernel-doc for 'slave' and 'irq' in struct axxia_i2c_dev. Drop kernel-doc notation ("/**") for static functions since they are not usually documented with kernel-doc. Prevents these kernel-doc warnings: i2c-axxia.c:150: warning: Function parameter or member 'slave' not described in 'axxia_i2c_dev' i2c-axxia.c:150: warning: Function parameter or member 'irq' not described in 'axxia_i2c_dev' i2c-axxia.c:172: warning: Function parameter or member 'ns' not described in 'ns_to_clk' i2c-axxia.c:172: warning: Function parameter or member 'clk_mhz' not described in 'ns_to_clk' i2c-axxia.c:172: warning: No description found for return value of 'ns_to_clk' i2c-axxia.c:271: warning: Function parameter or member 'idev' not described in 'axxia_i2c_empty_rx_fifo' i2c-axxia.c:271: warning: No description found for return value of 'axxia_i2c_empty_rx_fifo' i2c-axxia.c:303: warning: Function parameter or member 'idev' not described in 'axxia_i2c_fill_tx_fifo' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/all/202310181049.Vo62moV1-lkp@intel.com/ Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-28kbuild: Correct missing architecture-specific hyphensSimon Glass
These should add a hyphen to indicate that it makes a adjective. Fix them. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28modpost: squash ALL_{INIT,EXIT}_TEXT_SECTIONS to ALL_TEXT_SECTIONSMasahiro Yamada
ALL_INIT_TEXT_SECTIONS and ALL_EXIT_TEXT_SECTIONS are only used in the macro definition of ALL_TEXT_SECTIONS. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28modpost: merge sectioncheck table entries regarding init/exit sectionsMasahiro Yamada
Check symbol references from normal sections to init/exit sections in a single entry. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28modpost: use ALL_INIT_SECTIONS for the section check from DATA_SECTIONSMasahiro Yamada
ALL_INIT_SECTIONS is defined as follows: #define ALL_INIT_SECTIONS INIT_SECTIONS, ALL_XXXINIT_SECTIONS Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28modpost: disallow the combination of EXPORT_SYMBOL and __meminit*Masahiro Yamada
Theoretically, we could export conditionally-discarded code sections, such as .meminit*, if all the users can become modular under a certain condition. However, that would be difficult to control and such a tricky case has never occurred. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28modpost: remove EXIT_SECTIONS macroMasahiro Yamada
ALL_EXIT_SECTIONS and EXIT_SECTIONS are the same. Remove the latter. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28modpost: remove MEM_INIT_SECTIONS macroMasahiro Yamada
ALL_XXXINIT_SECTIONS and MEM_INIT_SECTIONS are the same. Remove the latter. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28modpost: remove more symbol patterns from the section check whitelistMasahiro Yamada
These symbol patterns were whitelisted to allow them to reference to functions with the old __devinit and __devexit annotations. We stopped doing this a long time ago, for example, commit 6f039790510f ("Drivers: scsi: remove __dev* attributes.") remove those annotations from the scsi drivers. Keep *_ops, *_probe, and *_console, otherwise they will really cause section mismatch warnings. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28modpost: disallow *driver to reference .meminit* sectionsMasahiro Yamada
Drivers must not reference .meminit* sections, which are discarded when CONFIG_MEMORY_HOTPLUG=n. The reason for whitelisting "*driver" in the section mismatch check was to allow drivers to reference symbols annotated as __devinit or __devexit that existed in the past. Those annotations were removed by the following commits: - 54b956b90360 ("Remove __dev* markings from init.h") - 92e9e6d1f984 ("modpost.c: Stop checking __dev* section mismatches") Remove the stale whitelist. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28linux/init: remove __memexit* annotationsMasahiro Yamada
We have never used __memexit, __memexitdata, or __memexitconst. These were unneeded. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de>
2023-10-28modpost: remove ALL_EXIT_DATA_SECTIONS macroMasahiro Yamada
This is unused. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28dt-bindings: i2c: i2c-demux-pinctrl: Convert to json-schemaGeert Uytterhoeven
Convert the pinctrl-based I2C bus demultiplexer Device Tree binding documentation to json-schema. Update the example to match reality. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-28kbuild: simplify cmd_ld_multi_mMasahiro Yamada
$(patsubst %.o,%.mod,$@) can be replaced with $<. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-10-28kbuild: avoid too many execution of scripts/pahole-flags.shMasahiro Yamada
scripts/pahole-flags.sh is executed so many times. You can confirm it, as follows: $ cat <<EOF >> scripts/pahole-flags.sh > echo "scripts/pahole-flags.sh was executed" >&2 > EOF $ make -s scripts/pahole-flags.sh was executed scripts/pahole-flags.sh was executed scripts/pahole-flags.sh was executed scripts/pahole-flags.sh was executed scripts/pahole-flags.sh was executed [ lots of repeated lines... ] This scripts is executed more than 20 times during the kernel build because PAHOLE_FLAGS is a recursively expanded variable and exported to sub-processes. With GNU Make >= 4.4, it is executed more than 60 times because exported variables are also passed to other $(shell ) invocations. Without careful coding, it is known to cause an exponential fork explosion. [1] The use of $(shell ) in an exported recursive variable is likely wrong because $(shell ) is always evaluated due to the 'export' keyword, and the evaluation can occur multiple times by the nature of recursive variables. Convert the shell script to a Makefile, which is included only when CONFIG_DEBUG_INFO_BTF=y. [1]: https://savannah.gnu.org/bugs/index.php?64746 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Tested-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Nicolas Schier <n.schier@avm.de> Tested-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
2023-10-28kbuild: remove ARCH_POSTLINK from module buildsMasahiro Yamada
The '%.ko' rule in arch/*/Makefile.postlink does nothing but call the 'true' command. Remove the unneeded code. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2023-10-28kbuild: unify no-compiler-targets and no-sync-config-targetsMasahiro Yamada
Now that vdso_install does not depend on any in-tree build artifact, it no longer needs a compiler, making no-compiler-targets the same as no-sync-config-targets. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2023-10-28kbuild: unify vdso_install rulesMasahiro Yamada
Currently, there is no standard implementation for vdso_install, leading to various issues: 1. Code duplication Many architectures duplicate similar code just for copying files to the install destination. Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication. 2. Unintended updates of in-tree build artifacts The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux"). 3. Broken code in some architectures Makefile code is often copied from one architecture to another without proper adaptation. 'make vdso_install' for parisc does not work. 'make vdso_install' for s390 installs vdso64, but not vdso32. To address these problems, this commit introduces a generic vdso_install rule. Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install. For example, arch/x86/Makefile looks like this: vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away. vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name. The following is a snippet from arch/arm64/Makefile. vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2023-10-28porting: update locking requirementsChristian Brauner
Now that s_umount is never taken under open_mutex update the documentation to say so. Link: https://lore.kernel.org/r/20231017184823.1383356-1-hch@lst.de Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28fs: assert that open_mutex isn't held over holder opsChristian Brauner
With recent block level changes we should never be in a situation where we hold disk->open_mutex when calling into these helpers. So assert that in the code. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20231017184823.1383356-6-hch@lst.de Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28block: assert that we're not holding open_mutex over blk_report_disk_deadChristian Brauner
blk_report_disk_dead() has the following major callers: (1) del_gendisk() (2) blk_mark_disk_dead() Since del_gendisk() acquires disk->open_mutex it's clear that all callers are assumed to be called without disk->open_mutex held. In turn, blk_report_disk_dead() is called without disk->open_mutex held in del_gendisk(). All callers of blk_mark_disk_dead() call it without disk->open_mutex as well. Ensure that it is clear that blk_report_disk_dead() is called without disk->open_mutex on purpose by asserting it and a comment in the code. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20231017184823.1383356-5-hch@lst.de Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28block: move bdev_mark_dead out of disk_check_media_changeChristoph Hellwig
disk_check_media_change is mostly called from ->open where it makes little sense to mark the file system on the device as dead, as we are just opening it. So instead of calling bdev_mark_dead from disk_check_media_change move it into the few callers that are not in an open instance. This avoid calling into bdev_mark_dead and thus taking s_umount with open_mutex held. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20231017184823.1383356-4-hch@lst.de Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-28block: WARN_ON_ONCE() when we remove active partitionsChristian Brauner
The logic for disk->open_partitions is: blkdev_get_by_*() -> bdev_is_partition() -> blkdev_get_part() -> blkdev_get_whole() // bdev_whole->bd_openers++ -> if (part->bd_openers == 0) disk->open_partitions++ part->bd_openers In other words, when we first claim/open a partition we increment disk->open_partitions and only when all part->bd_openers are closed will disk->open_partitions be zero. That should mean that disk->open_partitions is always > 0 as long as there's anyone that has an open partition. So the check for disk->open_partitions should mean that we can never remove an active partition that has a holder and holder ops set. Assert that in the code. The main disk isn't removed so that check doesn't work for disk->part0 which is what we want. After all we only care about partition not about the main disk. Link: https://lore.kernel.org/r/20231017184823.1383356-3-hch@lst.de Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Christian Brauner <brauner@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-15 11:25:08 +0000