summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* docs: filesystems: sysfs: Make text and code for ->show() consistentAndy Shevchenko2022-09-301-1/+1
| | | | | | | | | | The documentation says that ->show() should only use sysfs_emit() or sysfs_emit_at(), but example keeps outdated code. Update the code to be consistent. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220928135741.54919-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: NBD_REQUEST_MAGIC isn't a magic numberнаб2022-09-274-4/+0
| | | | | | | | | It's part of the line protocol, same as in commit 82805818898d ("Documentation: NBD_REPLY_MAGIC isn't a magic number") Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/20220927003727.slf4ofb7dgum6apt@tarta.nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* a.out: restore CMAGICнаб2022-09-261-0/+3
| | | | | | | | | | | | Part of UAPI and the on-disk format: this means that it's not a magic number per magic-number.rst, and it's best to leave it untouched to avoid breaking userspace and suffer the same fate as a.out in general Fixes: 53c2bd679017 ("a.out: remove define-only CMAGIC, previously magic number") Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/20220926151554.7gxd6unp5727vw3c@tarta.nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* device property: Add const qualifier to device_get_match_data() parameterAndy Shevchenko2022-09-242-4/+4
| | | | | | | | | | | | | | Add const qualifier to the device_get_match_data() parameter. Some of the future users may utilize this function without forcing the type. All the same, dev_fwnode() may be used with a const qualifier. Reported-by: kernel test robot <lkp@intel.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220922135410.49694-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm_print: add _ddebug descriptor to drm_*dbg prototypesJim Cromie2022-09-242-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct _ddebug ptr parameter to them, and supply that additional param by replacing the '_no_desc' flavor of dyndbg Factory macro currently used with the flavor that supplies the descriptor. NOTES: The descriptor gives these fns access to the decorator flags, but they do none of the dynamic-prefixing done by dynamic_emit_prefix(), which is currently static. DRM already has conventions for logging/messaging; just tossing optional decorations on top probably wouldn't help. Instead, existing flags (or new ones, perhaps 'sd' ala lspci) can be used to make current message conventions optional. This suggests a new drmdbg_prefix_emit() to handle prefixing locally. For CONFIG_DRM_USE_DYNAMIC_DEBUG=N, just pass null descriptor. desc->class_id is redundant with category parameter, but its availability is dependent on desc. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-10-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm_print: prefer bare printk KERN_DEBUG on generic fnJim Cromie2022-09-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_print.c calls pr_debug() just once, from __drm_printfn_debug(), which is a generic/service fn. The callsite is compile-time enabled by DEBUG in both DYNAMIC_DEBUG=y/n builds. For dyndbg builds, reverting this callsite back to bare printk is correcting a few anti-features: 1- callsite is generic, serves multiple drm users. it is soft-wired on currently by #define DEBUG could accidentally: #> echo -p > /proc/dynamic_debug/control 2- optional "decorations" by dyndbg are unhelpful/misleading here, they describe only the generic site, not end users IOW, 1,2 are unhelpful at best, and possibly confusing. reverting yields a nominal data and text shrink: text data bss dec hex filename 462583 36604 54592 553779 87333 /kernel/drivers/gpu/drm/drm.ko 462515 36532 54592 553639 872a7 -dirty/kernel/drivers/gpu/drm/drm.ko Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-9-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm_print: optimize drm_debug_enabled for jump-labelJim Cromie2022-09-242-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When CONFIG_DRM_USE_DYNAMIC_DEBUG=y, the drm.debug API (a macro stack, calling _+drm_*dbg() eventually) invokes a dyndbg Factory macro to create a descriptor for each callsite, thus making them individually >control-able. In this case, the calls to _drm_*dbg are unreachable unless the callsite is enabled. So those calls can short-circuit their early do-nothing returns. Provide and use __drm_debug_enabled(), to do this when config'd, or the _raw flags-check otherwize. And since dyndbg is in use, lets also instrument the remaining users of drm_debug_enabled, by wrapping the _raw in a macro with a: pr_debug("todo: is this frequent enough to optimize ?\n"); For CONFIG_DRM_USE_DYNAMIC_DEBUG=n, do no site instrumenting at all, since JUMP_LABEL might be off, and we don't want to make work. With drm, amdgpu, i915, nouveau loaded, heres remaining uses of drm_debug_enabled(), which costs ~1.5kb data to control the pr_debug("todo:..")s. Some of those uses might be ok to use __drm_debug_enabled() by inspection, others might warrant conversion to use dyndbg Factory macros, and that would want callrate data to estimate the savings possible. TBH, any remaining savings are probably small; drm.debug covers the vast bulk of the uses. Maybe "vblank" is the exception. :#> grep todo /proc/dynamic_debug/control | wc 21 168 2357 :#> grep todo /proc/dynamic_debug/control drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:787 [drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:1433 [drm]drm_vblank_enable =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_plane.c:2168 [drm]drm_mode_setplane =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:1359 [drm_display_helper]drm_dp_mst_wait_tx_reply =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:2864 [drm_display_helper]process_single_tx_qlock =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:2909 [drm_display_helper]drm_dp_queue_down_tx =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:1686 [drm_display_helper]drm_dp_mst_update_slots =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_dp.c:1111 [i915]intel_dp_print_rates =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_backlight.c:5434 [i915]cnp_enable_backlight =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_backlight.c:5459 [i915]intel_backlight_device_register =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_opregion.c:43 [i915]intel_opregion_notify_encoder =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_opregion.c:53 [i915]asle_set_backlight =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_bios.c:1088 [i915]intel_bios_is_dsi_present =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_display_debugfs.c:6153 [i915]i915_drrs_ctl_set =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/intel_pcode.c:26 [i915]snb_pcode_read =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/i915_getparam.c:785 [i915]i915_getparam_ioctl =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:282 [amdgpu]vcn_v2_5_process_interrupt =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:433 [amdgpu]vcn_v2_0_process_interrupt =_ "todo: maybe avoid via dyndbg\n" :#> Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-8-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm-print: add drm_dbg_driver to improve namespace symmetryJim Cromie2022-09-241-1/+2
| | | | | | | | | | | | | | | | | | drm_print defines all of these: drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres} but not drm_dbg_driver itself, since it was the original drm_dbg. To improve namespace symmetry, change the drm_dbg defn to drm_dbg_driver, and redef grandfathered name to symmetric one. This will help with nouveau, which uses its own stack of macros to construct calls to dev_info, dev_dbg, etc, for which adaptation means drm_dbg_##driver constructs. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-7-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm-print.h: include dyndbg headerJim Cromie2022-09-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | lkp robot told me: >> drivers/gpu/drm/drm_ioc32.c:989:2: error: call to undeclared function '_dynamic_func_call_cls'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n", Since that macro is defined in drm_print.h, and under DRM_USE_DYN*=y configs, invokes dyndbg-factory macros, include dynamic_debug.h from there too, so that those configs have the definitions of all the macros in the callchain. This is done as a separate patch mostly to see how lkp sorts it. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-6-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm_print: wrap drm_*_dbg in dyndbg descriptor factory macroJim Cromie2022-09-243-0/+26
| | | | | | | | | | | | | | | | | | | For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg() in one of dyndbg's Factory macros: _dynamic_func_call_no_desc(). This adds the callsite descriptor into the code, and an entry for each into /proc/dynamic_debug/control. #> echo class DRM_UT_ATOMIC +p > /proc/dynamic_debug/control CONFIG_DRM_USE_DYNAMIC_DEBUG=y/n is configurable because of the .data footprint cost of per-callsite control; 56 bytes/site * ~2k for i915, ~4k callsites for amdgpu. This is large enough that a kernel builder might not want it. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-5-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm_print: interpose drm_*dbg with forwarding macrosJim Cromie2022-09-242-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | change drm_dev_dbg & drm_dbg to macros, which forward to the renamed functions (with __ prefix added). Those functions sit below the categorized layer of macros implementing the DRM debug.category API, and implement most of it. These are good places to insert dynamic-debug jump-label mechanics, which will allow DRM to avoid the runtime cost of drm_debug_enabled(). no functional changes. memory cost baseline: (unchanged) bash-5.1# drms_load [ 9.220389] dyndbg: 1 debug prints in module drm [ 9.224426] ACPI: bus type drm_connector registered [ 9.302192] dyndbg: 2 debug prints in module ttm [ 9.305033] dyndbg: 8 debug prints in module video [ 9.627563] dyndbg: 127 debug prints in module i915 [ 9.721505] AMD-Vi: AMD IOMMUv2 functionality not available on this system - This is not a bug. [ 10.091345] dyndbg: 2196 debug prints in module amdgpu [ 10.106589] [drm] amdgpu kernel modesetting enabled. [ 10.107270] amdgpu: CRAT table not found [ 10.107926] amdgpu: Virtual CRAT table created for CPU [ 10.108398] amdgpu: Topology: Add CPU node [ 10.168507] dyndbg: 3 debug prints in module wmi [ 10.329587] dyndbg: 3 debug prints in module nouveau Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-4-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.Jim Cromie2022-09-247-3/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use DECLARE_DYNDBG_CLASSMAP across DRM: - in .c files, since macro defines/initializes a record - in drivers, $mod_{drv,drm,param}.c ie where param setup is done, since a classmap is param related - in drm/drm_print.c since existing __drm_debug param is defined there, and we ifdef it, and provide an elaborated alternative. - in drm_*_helper modules: dp/drm_dp - 1st item in makefile target drivers/gpu/drm/drm_crtc_helper.c - random pick iirc. Since these modules all use identical CLASSMAP declarations (ie: names and .class_id's) they will all respond together to "class DRM_UT_*" query-commands: :#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control NOTES: This changes __drm_debug from int to ulong, so BIT() is usable on it. DRM's enum drm_debug_category values need to sync with the index of their respective class-names here. Then .class_id == category, and dyndbg's class FOO mechanisms will enable drm_dbg(DRM_UT_KMS, ...). Though DRM needs consistent categories across all modules, thats not generally needed; modules X and Y could define FOO differently (ie a different NAME => class_id mapping), changes are made according to each module's private class-map. No callsites are actually selected by this patch, since none are class'd yet. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-3-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm_print: condense enum drm_debug_categoryJim Cromie2022-09-241-11/+11
| | | | | | | | | | | | | | | | | | | | | | enum drm_debug_category has 10 categories, but is initialized with bitmasks which require 10 bits of underlying storage. By using natural enumeration, and moving the BIT(cat) into drm_debug_enabled(), the enum fits in 4 bits, allowing the category to be represented directly in pr_debug callsites, via the ddebug.class_id field. While this slightly pessimizes the bit-test in drm_debug_enabled(), using dyndbg with JUMP_LABEL will avoid the function entirely. NOTE: this change forecloses the possibility of doing: drm_dbg(DRM_UT_CORE|DRM_UT_KMS, "weird 2-cat experiment") but thats already strongly implied by the use of the enum itself; its not a normal enum if it can be 2 values simultaneously. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-2-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* debugfs: use DEFINE_SHOW_ATTRIBUTE to define debugfs_regset32_fopsChenXiaoSong2022-09-241-13/+3
| | | | | | | | Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code. Signed-off-by: ChenXiaoSong <chenxiaosong2@huawei.com> Link: https://lore.kernel.org/r/20220923102554.2443452-1-chenxiaosong2@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: use IS_ERR_OR_NULL() helper in device_create_groups_vargs()Yang Yingliang2022-09-241-1/+1
| | | | | | | | | Use IS_ERR_OR_NULL() helper in device_create_groups_vargs() to simplify code and improve readiblity. No functional change. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220914140753.3799982-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: ENI155_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | It's part of the EEPROM format Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/5f1dfa09150be7f23fb275d170c9019b5197a79f.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: NBD_REPLY_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | It's part of the line protocol Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/a8afed8fb4d7df2c8fb95c3fa758240b2e46cdc8.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* nbd: remove define-only NBD_MAGIC, previously magic numberнаб2022-09-245-6/+0
| | | | | | | | | | commit f4507164e779 ("nbd: rename the nbd_device variable from lo to nbd") renamed LO_MAGIC to NBD_MAGIC; commit 5ea8d10802ec ("nbd: separate out the config information") removed the last users of that Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/10a80681c5966fed1a1afc696e3db114f481514c.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: FW_HEADER_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | It's a file format identifier Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/1b21808fb399931eb44f0dc26fda20a632ecc196.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: EEPROM_MAGIC_VALUE isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | It's an EEPROM checksum, not a magic number per magic-number.rst Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/8881090c8bf1850e1d3597cb352a8dd1757c94f1.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: COW_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | At least not in the magic-number.rst sense: it's part of a file format Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/f24a428d82713821ca571bf477a099252d06ae14.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: SAVEKMSG_MAGIC[12] aren't magic numbersнаб2022-09-244-8/+0
| | | | | | | | | | At least not in the magic-number.rst sense: they're used as part of delineating messages dumping dmesg into Chip RAM on the Amiga with debug=ram Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/c0fe3aadb700621eeee736f0ce6d73aa9d2cf856.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: RIEBL_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | At least not in the sense described in magic-number.rst: it determines whether the Atari VME Lance Ethernet card has a hardware MAC address or not, and is set thereby to indicate this Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/773e5a8fe80201bed0dff5cdb1ce6f4272b0cc92.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: FULL_DUPLEX_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | It's used to control a mysterious register on the DEC DE21040, see comment in drivers/net/ethernet/dec/tulip/de2104x.c Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/ff28a15f9154589788277807523aa71c45c24d28.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: CG_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | | At least not in the sense described here: it delineates UFS cylinder groups, is never assigned, and the only macro that incorporates it (ufs_cg_chkmagic; the second one is unused) is used to detect CGs and protect from filesystem corruption Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/a508477cfeb18eca4a24c29836f809fe34f20467.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: zh: remove stale magic numbersнаб2022-09-242-4/+0
| | | | | | | | | | | | | | | | | | English and it magic-number.rsts were updated when these were removed; the zh translations weren't This equalises these lists to be the same across all translations Automated: grep MAGIC Documentation/translations/process/zh_TW/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -vq \ '^Documentation.*magic-number.rst:' || sed -i "/^$mag/d" \ ./Documentation/{,translations/{zh_CN,zh_TW,it_IT}/}process/magic-number.rst ; done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/5d9fa062178c45822a600a723f6f71fdb92011f3.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: zh: remove references to IrDAнаб2022-09-242-4/+0
| | | | | | | | | | These lines blame back to their first appearance which cites linux-2.6, and IrDA was finally fully removed in 4.17 with commit d64c2a76123f ("staging: irda: remove the irda network stack and drivers") Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/d07ce5b1bc173fd02b7e5b708beb81b9432745f8.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: sndmagic.h doesn't existнаб2022-09-244-17/+0
| | | | | | | | | | | It was added in 2.5.5 and removed in a 2.6.9 "ALSA CVS update", pre-git, which states: Removal and replacement of magic memory allocators and casts (core part) Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/09e56999b0b323fb0add61f7dbd8c9f0a576561a.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: HFS is not a user of magic numbersнаб2022-09-244-11/+0
| | | | | | | | | | | | | In fs/hfs, the only magic is for delineating on-disk block types, of which HFS_DRVR_DESC_MAGIC HFS_MFS_SUPER_MAGIC are define-only, but they're out of scope for magic-number.rst Magic numbers as described there were all removed, along their defines, in the 2.6.4 "HFS rewrite", pre-git Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/e67cec702a7ab34a8c5f7966d930d793a097a90f.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* MIPS: remove define-only GDA_MAGIC, previously magic numberнаб2022-09-245-6/+0
| | | | | | | | | | | | | | The last user was removed in the 2.6.4 "MIPS mega-patch", pre-git Found with grep MAGIC Documentation/process/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -ve '^Documentation.*magic-number.rst:' \ -qe ':#define '"$mag" || git grep -wF "$mag" | while IFS=: read -r f _; do sed -i '/\b'"$mag"'\b/d' "$f"; done ; done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/c2e7510beebdd698e20d0704712e623fad00fc1c.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Bluetooth: RFCOMM: remove define-only RFCOMM_TTY_MAGIC ex-magic-numberнаб2022-09-245-5/+0
| | | | | | | | | | | | | | Appeared in its present state in pre-git (2.5.41), never used Found with grep MAGIC Documentation/process/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -ve '^Documentation.*magic-number.rst:' \ -qe ':#define '"$mag" || git grep -wF "$mag" | while IFS=: read -r f _; do sed -i '/\b'"$mag"'\b/d' "$f"; done ; done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/f6d375201dfd99416ea03b49b3dd40af56c1537e.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* a.out: remove define-only CMAGIC, previously magic numberнаб2022-09-245-7/+0
| | | | | | | | | | | | | | | | | | | | | The last user was removed in 5.1 in commit 08300f4402ab ("a.out: remove core dumping support") but this is part of the UAPI headers, so this may want to either wait until a.out is removed entirely, or be removed from the magic number doc and silently remain in the header A cursory glance on DCS didn't show any user code actually using this value Found with grep MAGIC Documentation/process/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -ve '^Documentation.*magic-number.rst:' \ -qe ':#define '"$mag" || git grep -wF "$mag" | while IFS=: read -r f _; do sed -i '/\b'"$mag"'\b/d' "$f"; done ; done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/9cbea062df7125ef43e2e0b2a67ede6ad1c5f27e.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: remove nonexistent magic numbersнаб2022-09-244-168/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The entire file blames back to the start of git (minus whitespace from the RST translation and a typo fix): * there are changelog comments for March 1994 through to Linux 2.5.74 * struct tty_ldisc is two pointers nowadays, so naturally no magic * GDA_MAGIC is defined but unused, and it's been this way since start-of-git * M3_CARD_MAGIC isn't defined, because commit d56b9b9c464a ("[PATCH] The scheduled removal of some OSS drivers") removed the entire driver in 2006 * CS_CARD_MAGIC likewise since commit b5d425c97f7d ("more scheduled OSS driver removal") in 2007 * KMALLOC_MAGIC and VMALLOC_MAGIC were removed in commit e38e0cfa48ac ("[ALSA] Remove kmalloc wrappers"), six months after start of git * SLAB_C_MAGIC has never even appeared in git (removed in 2.4.0-test3pre6) magic-number.rst is a low-value historial relic at best and misleading cruft at worst, so start with cleaning out ones that only appear therein Automated: grep MAGIC Documentation/process/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -vq '^Documentation.*magic-number.rst:' || sed -i "/^$mag/d" \ Documentation/{,translations/{zh_CN,zh_TW,it_IT}/}process/magic-number.rst done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/8389a7b85b5c660c6891b1740b5dacc53491a41b.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* devcoredump : Serialize devcd_del workMukesh Ojha2022-09-241-2/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In following scenario(diagram), when one thread X running dev_coredumpm() adds devcd device to the framework which sends uevent notification to userspace and another thread Y reads this uevent and call to devcd_data_write() which eventually try to delete the queued timer that is not initialized/queued yet. So, debug object reports some warning and in the meantime, timer is initialized and queued from X path. and from Y path, it gets reinitialized again and timer->entry.pprev=NULL and try_to_grab_pending() stucks. To fix this, introduce mutex and a boolean flag to serialize the behaviour. cpu0(X) cpu1(Y) dev_coredump() uevent sent to user space device_add() ======================> user space process Y reads the uevents writes to devcd fd which results into writes to devcd_data_write() mod_delayed_work() try_to_grab_pending() del_timer() debug_assert_init() INIT_DELAYED_WORK() schedule_delayed_work() debug_object_fixup() timer_fixup_assert_init() timer_setup() do_init_timer() /* Above call reinitializes the timer to timer->entry.pprev=NULL and this will be checked later in timer_pending() call. */ timer_pending() !hlist_unhashed_lockless(&timer->entry) !h->pprev /* del_timer() checks h->pprev and finds it to be NULL due to which try_to_grab_pending() stucks. */ Link: https://lore.kernel.org/lkml/2e1f81e2-428c-f11f-ce92-eb11048cb271@quicinc.com/ Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/1663073424-13663-1-git-send-email-quic_mojha@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* debugfs: Only clobber mode/uid/gid on remount if askedBrian Norris2022-09-241-7/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users may have explicitly configured their debugfs permissions; we shouldn't overwrite those just because a second mount appeared. Only clobber if the options were provided at mount time. Existing behavior: ## Pre-existing status: debugfs is 0755. # chmod 755 /sys/kernel/debug/ # stat -c '%A' /sys/kernel/debug/ drwxr-xr-x ## New mount sets kernel-default permissions: # mount -t debugfs none /mnt/foo # stat -c '%A' /mnt/foo drwx------ ## Unexpected: the original mount changed permissions: # stat -c '%A' /sys/kernel/debug drwx------ New behavior: ## Pre-existing status: debugfs is 0755. # chmod 755 /sys/kernel/debug/ # stat -c '%A' /sys/kernel/debug/ drwxr-xr-x ## New mount inherits existing permissions: # mount -t debugfs none /mnt/foo # stat -c '%A' /mnt/foo drwxr-xr-x ## Expected: old mount is unchanged: # stat -c '%A' /sys/kernel/debug drwxr-xr-x Full test cases are being submitted to LTP. Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20220912163042.v3.1.Icbd40fce59f55ad74b80e5d435ea233579348a78@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kernfs: fix use-after-free in __kernfs_removeChristian A. Ehrhardt2022-09-241-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Syzkaller managed to trigger concurrent calls to kernfs_remove_by_name_ns() for the same file resulting in a KASAN detected use-after-free. The race occurs when the root node is freed during kernfs_drain(). To prevent this acquire an additional reference for the root of the tree that is removed before calling __kernfs_remove(). Found by syzkaller with the following reproducer (slab_nomerge is required): syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0) r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0) close(r0) pipe2(&(0x7f0000000140)={0xffffffffffffffff, <r1=>0xffffffffffffffff}, 0x800) mount$9p_fd(0x0, &(0x7f0000000040)='./file0\x00', &(0x7f00000000c0), 0x408, &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c, {[{@cache_loose}, {@mmap}, {@loose}, {@loose}, {@mmap}], [{@mask={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}}) Sample report: ================================================================== BUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline] BUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline] BUG: KASAN: use-after-free in __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 Read of size 2 at addr ffff8880088807f0 by task syz-executor.2/857 CPU: 0 PID: 857 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x5e/0x5e5 mm/kasan/report.c:433 kasan_report+0xa3/0x130 mm/kasan/report.c:495 kernfs_type include/linux/kernfs.h:335 [inline] kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline] __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 __kernfs_remove fs/kernfs/dir.c:1356 [inline] kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589 sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943 __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126 legacy_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f725f983aed Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed RDX: 00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000 RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000 R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000006 R14: 00007f725faa3f80 R15: 00007f725f0d7000 </TASK> Allocated by task 855: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:470 kasan_slab_alloc include/linux/kasan.h:224 [inline] slab_post_alloc_hook mm/slab.h:727 [inline] slab_alloc_node mm/slub.c:3243 [inline] slab_alloc mm/slub.c:3251 [inline] __kmem_cache_alloc_lru mm/slub.c:3258 [inline] kmem_cache_alloc+0xbf/0x200 mm/slub.c:3268 kmem_cache_zalloc include/linux/slab.h:723 [inline] __kernfs_new_node+0xd4/0x680 fs/kernfs/dir.c:593 kernfs_new_node fs/kernfs/dir.c:655 [inline] kernfs_create_dir_ns+0x9c/0x220 fs/kernfs/dir.c:1010 sysfs_create_dir_ns+0x127/0x290 fs/sysfs/dir.c:59 create_dir lib/kobject.c:63 [inline] kobject_add_internal+0x24a/0x8d0 lib/kobject.c:223 kobject_add_varg lib/kobject.c:358 [inline] kobject_init_and_add+0x101/0x160 lib/kobject.c:441 sysfs_slab_add+0x156/0x1e0 mm/slub.c:5954 __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126 legacy_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 857: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:367 [inline] ____kasan_slab_free mm/kasan/common.c:329 [inline] __kasan_slab_free+0x108/0x190 mm/kasan/common.c:375 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1754 [inline] slab_free_freelist_hook mm/slub.c:1780 [inline] slab_free mm/slub.c:3534 [inline] kmem_cache_free+0x9c/0x340 mm/slub.c:3551 kernfs_put.part.0+0x2b2/0x520 fs/kernfs/dir.c:547 kernfs_put+0x42/0x50 fs/kernfs/dir.c:521 __kernfs_remove.part.0+0x72d/0x960 fs/kernfs/dir.c:1407 __kernfs_remove fs/kernfs/dir.c:1356 [inline] kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589 sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943 __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126 legacy_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The buggy address belongs to the object at ffff888008880780 which belongs to the cache kernfs_node_cache of size 128 The buggy address is located 112 bytes inside of 128-byte region [ffff888008880780, ffff888008880800) The buggy address belongs to the physical page: page:00000000732833f8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8880 flags: 0x100000000000200(slab|node=0|zone=1) raw: 0100000000000200 0000000000000000 dead000000000122 ffff888001147280 raw: 0000000000000000 0000000000150015 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888008880680: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888008880700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff888008880780: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888008880800: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888008880880: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Acked-by: Tejun Heo <tj@kernel.org> Cc: stable <stable@kernel.org> # -rc3 Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Link: https://lore.kernel.org/r/20220913121723.691454-1-lk@c--e.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 1707c39ae309 ("Merge tag 'driver-core-6.0-rc7' of ↵Greg Kroah-Hartman2022-09-24366-2635/+3084
|\ | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core") driver-core-next This merges the driver core changes in 6.0-rc7 into driver-core-next as they are needed here as well for testing. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Merge tag 'driver-core-6.0-rc7' of ↵Linus Torvalds2022-09-232-3/+4
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fixes from Greg KH: "Here are two tiny driver core fixes for 6.0-rc7 that resolve some oft-reported problems. The first is a revert of the "fw_devlink.strict=1" default option that we keep trying to enable, but we keep finding platforms that this just breaks everything on. So again, we need it reverted and hopefully it can be worked on in future releases. The second is a sysfs file-size bugfix that resolves an issue that many people are starting to hit as the fix it is fixing also was backported to stable kernels. The util-linux developers are starting to get bugreports about sysfs files that contain no data because of this problem, and this fix which has been in linux-next in the bitfield tree for a long time, resolves it. I'm submitting it here as it needs to be merged for 6.0-final, not for 6.1-rc1. Both of these have been in linux-next with no reported issues, only reports were that these fixed problems" * tag 'driver-core-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: drivers/base: Fix unsigned comparison to -1 in CPUMAP_FILE_MAX_BYTES Revert "driver core: Set fw_devlink.strict=1 by default"
| | * drivers/base: Fix unsigned comparison to -1 in CPUMAP_FILE_MAX_BYTESPhil Auld2022-09-221-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As PAGE_SIZE is unsigned long, -1 > PAGE_SIZE when NR_CPUS <= 3. This leads to very large file sizes: topology$ ls -l total 0 -r--r--r-- 1 root root 18446744073709551615 Sep 5 11:59 core_cpus -r--r--r-- 1 root root 4096 Sep 5 11:59 core_cpus_list -r--r--r-- 1 root root 4096 Sep 5 10:58 core_id -r--r--r-- 1 root root 18446744073709551615 Sep 5 10:10 core_siblings -r--r--r-- 1 root root 4096 Sep 5 11:59 core_siblings_list -r--r--r-- 1 root root 18446744073709551615 Sep 5 11:59 die_cpus -r--r--r-- 1 root root 4096 Sep 5 11:59 die_cpus_list -r--r--r-- 1 root root 4096 Sep 5 11:59 die_id -r--r--r-- 1 root root 18446744073709551615 Sep 5 11:59 package_cpus -r--r--r-- 1 root root 4096 Sep 5 11:59 package_cpus_list -r--r--r-- 1 root root 4096 Sep 5 10:58 physical_package_id -r--r--r-- 1 root root 18446744073709551615 Sep 5 10:10 thread_siblings -r--r--r-- 1 root root 4096 Sep 5 11:59 thread_siblings_list Adjust the inequality to catch the case when NR_CPUS is configured to a small value. Fixes: 7ee951acd31a ("drivers/base: fix userspace break from using bin_attributes for cpumap and cpulist") Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Yury Norov <yury.norov@gmail.com> Cc: stable@vger.kernel.org Cc: feng xiangjun <fengxj325@gmail.com> Reported-by: feng xiangjun <fengxj325@gmail.com> Signed-off-by: Phil Auld <pauld@redhat.com> Signed-off-by: Yury Norov <yury.norov@gmail.com> Link: https://lore.kernel.org/r/20220906203542.1796629-1-pauld@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * Revert "driver core: Set fw_devlink.strict=1 by default"Greg Kroah-Hartman2022-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 71066545b48e4259f89481199a0bbc7c35457738. It causes boot problems on some systems, so revert it for now until it is worked out. Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Saravana Kannan <saravanak@google.com> Fixes: 71066545b48e ("driver core: Set fw_devlink.strict=1 by default") Reported-by: Olof Johansson <olof@lixom.net> Link: https://lore.kernel.org/r/CAOesGMjQHhTUMBGHQcME4JBkZCof2NEQ4gaM1GWFgH40+LN9AQ@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | Merge tag 'usb-6.0-rc7' of ↵Linus Torvalds2022-09-237-8/+18
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB / Thunderbolt driver fixes and ids from Greg KH: "Here are a few small USB and Thunderbolt driver fixes and new device ids for 6.0-rc7. They contain: - new usb-serial driver ids - documentation build warning fix in USB hub code - flexcop-usb long-posted bugfix (the v4l maintainer for this is MIA so I have finally picked this up as it is a fix for a reported problem.) - dwc3 64bit DMA bugfix - new thunderbolt device ids - typec build error fix All of these have been in linux-next with no reported issues" * tag 'usb-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: typec: anx7411: Fix build error without CONFIG_POWER_SUPPLY media: flexcop-usb: fix endpoint type check USB: serial: option: add Quectel RM520N USB: serial: option: add Quectel BG95 0x0203 composition thunderbolt: Add support for Intel Maple Ridge single port controller usb: dwc3: core: leave default DMA if the controller does not support 64-bit DMA USB: core: Fix RST error in hub.c
| | * \ Merge tag 'usb-serial-6.0-rc7' of ↵Greg Kroah-Hartman2022-09-221-0/+6
| | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: "USB-serial fixes for 6.0-rc7 Here are some new modem device ids. All have been in linux-next with no reported issues." * tag 'usb-serial-6.0-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Quectel RM520N USB: serial: option: add Quectel BG95 0x0203 composition
| | | * | USB: serial: option: add Quectel RM520Njerry meng2022-09-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | add support for Quectel RM520N which is based on Qualcomm SDX62 chip. 0x0801: DIAG + NMEA + AT + MODEM + RMNET T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0801 Rev= 5.04 S: Manufacturer=Quectel S: Product=RM520N-GL S: SerialNumber=384af524 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: jerry meng <jerry-meng@foxmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
| | | * | USB: serial: option: add Quectel BG95 0x0203 compositionCarl Yin(殷张成)2022-09-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the following Quectel BG95 composition: 0x0203: Diag + GNSS + Modem + ECM usb-devices output: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0203 Rev= 0.00 S: Manufacturer=Quectel, Incorporated S: Product=Quectel LPWA Module S: SerialNumber=71d3a21b C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 3 IfCount= 2 Cls=02(comm.) Sub=00 Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms I: If#= 4 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Carl Yin <carl.yin@quectel.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
| | * | | usb: typec: anx7411: Fix build error without CONFIG_POWER_SUPPLYRen Zhijie2022-09-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Building without CONFIG_POWER_SUPPLY will fail: drivers/usb/typec/anx7411.o: In function `anx7411_detect_power_mode': anx7411.c:(.text+0x527): undefined reference to `power_supply_changed' drivers/usb/typec/anx7411.o: In function `anx7411_psy_set_prop': anx7411.c:(.text+0x90d): undefined reference to `power_supply_get_drvdata' anx7411.c:(.text+0x930): undefined reference to `power_supply_changed' drivers/usb/typec/anx7411.o: In function `anx7411_psy_get_prop': anx7411.c:(.text+0x94d): undefined reference to `power_supply_get_drvdata' drivers/usb/typec/anx7411.o: In function `anx7411_i2c_probe': anx7411.c:(.text+0x111d): undefined reference to `devm_power_supply_register' drivers/usb/typec/anx7411.o: In function `anx7411_work_func': anx7411.c:(.text+0x167c): undefined reference to `power_supply_changed' anx7411.c:(.text+0x1b55): undefined reference to `power_supply_changed' Add POWER_SUPPLY dependency to Kconfig. Fixes: fe6d8a9c8e64 ("usb: typec: anx7411: Add Analogix PD ANX7411 support") Reviewed-by: Xin Ji <xji@analogixsemi.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Ren Zhijie <renzhijie2@huawei.com> Link: https://lore.kernel.org/r/20220920084431.196258-1-renzhijie2@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | media: flexcop-usb: fix endpoint type checkJohan Hovold2022-09-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type") tried to add an endpoint type sanity check for the single isochronous endpoint but instead broke the driver by checking the wrong descriptor or random data beyond the last endpoint descriptor. Make sure to check the right endpoint descriptor. Fixes: d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type") Cc: Oliver Neukum <oneukum@suse.com> Cc: stable@vger.kernel.org # 5.9 Reported-by: Dongliang Mu <mudongliangabcd@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20220822151027.27026-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | Merge tag 'thunderbolt-for-v6.0-rc6' of ↵Greg Kroah-Hartman2022-09-152-0/+2
| | |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus Mika writes: "thunderbolt: Fix for v6.0-rc6 This includes a single commit adding missing PCI ID for Intel Maple Ridge Thunderbolt 4 single port controller. This has been in linux-next with no reported issues." * tag 'thunderbolt-for-v6.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Add support for Intel Maple Ridge single port controller
| | | * | | thunderbolt: Add support for Intel Maple Ridge single port controllerGil Fine2022-09-092-0/+2
| | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for Maple Ridge discrete USB4 host controller from Intel which has a single USB4 port (versus the already supported dual port Maple Ridge USB4 host controller). Cc: stable@vger.kernel.org Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | usb: dwc3: core: leave default DMA if the controller does not support 64-bit DMAWilliam Wu2022-09-071-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some DWC3 controllers (e.g. Rockchip SoCs), the DWC3 core doesn't support 64-bit DMA address width. In this case, this driver should use the default 32-bit mask. Otherwise, the DWC3 controller will break if it runs on above 4GB physical memory environment. This patch reads the DWC_USB3_AWIDTH bits of GHWPARAMS0 which used for the DMA address width, and only configure 64-bit DMA mask if the DWC_USB3_AWIDTH is 64. Fixes: 45d39448b4d0 ("usb: dwc3: support 64 bit DMA in platform driver") Cc: stable <stable@kernel.org> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: William Wu <william.wu@rock-chips.com> Link: https://lore.kernel.org/r/20220901083446.3799754-1-william.wu@rock-chips.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | USB: core: Fix RST error in hub.cAlan Stern2022-09-051-1/+1
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recent commit added an invalid RST expression to a kerneldoc comment in hub.c. The fix is trivial. Fixes: 9c6d778800b9 ("USB: core: Prevent nested device-reset calls") Cc: <stable@vger.kernel.org> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/YxDDcsLtRZ7c20pq@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-18 21:54:52 +0000