- 13 Aug, 2020 22 commits
-
-
Suman Anna authored
The DT node full name is currently being used in regmap_config which in turn is used to create the regmap debugfs directories. This name however is not guaranteed to be unique and the regmap debugfs registration can fail in the cases where the syscon nodes have the same unit-address but are present in different DT node hierarchies. Replace this logic using the syscon reg resource address instead (inspired from logic used while creating platform devices) to ensure a unique name is given for each syscon. Signed-off-by:
Suman Anna <s-anna@ti.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Lee Jones <lee.jones@linaro.org>
-
Alexander A. Klimov authored
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by:Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Andy Shevchenko authored
The event handler loop must be run with interrupts disabled. Otherwise we will have a warning: [ 1970.785649] irq 31 handler lineevent_irq_handler+0x0/0x20 enabled interrupts [ 1970.792739] WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x162/0x170 [ 1970.860732] RIP: 0010:__handle_irq_event_percpu+0x162/0x170 ... [ 1970.946994] Call Trace: [ 1970.949446] <IRQ> [ 1970.951471] handle_irq_event_percpu+0x2c/0x80 [ 1970.955921] handle_irq_event+0x23/0x43 [ 1970.959766] handle_simple_irq+0x57/0x70 [ 1970.963695] generic_handle_irq+0x42/0x50 [ 1970.967717] dln2_rx+0xc1/0x210 [dln2] [ 1970.971479] ? usb_hcd_unmap_urb_for_dma+0xa6/0x1c0 [ 1970.976362] __usb_hcd_giveback_urb+0x77/0xe0 [ 1970.980727] usb_giveback_urb_bh+0x8e/0xe0 [ 1970.984837] tasklet_action_common.isra.0+0x4a/0xe0 ... Recently xHCI driver switched to tasklets in the commit 36dc0165 ("usb: host: xhci: Support running urb giveback in tasklet context"). The handle_irq_event_* functions are expected to be called with interrupts disabled and they rightfully complain here because we run in tasklet context with interrupts enabled. Use a event spinlock to protect event handler from being interrupted. Note, that there are only two users of this GPIO and ADC drivers and both of them are using generic_handle_irq() which makes above happen. Fixes: 338a1281 ("mfd: Add support for Diolan DLN-2 devices") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Charles Keepax authored
The current unbinding process for Madera has some issues. The trouble is runtime PM is disabled as the first step of the process, but some of the drivers release IRQs causing regmap IRQ to issue a runtime get which fails. To allow runtime PM to remain enabled during mfd_remove_devices, the DCVDD regulator must remain available. In the case of external DCVDD's this is simple, the regulator can simply be disabled/put after the call to mfd_remove_devices. However, in the case of an internally supplied DCVDD the regulator needs to be released after the other MFD children depending on it. Use the new MFD mfd_remove_devices_late functionality to split the DCVDD regulator off from the other drivers. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Charles Keepax authored
Currently, the only way to remove MFD children is with a call to mfd_remove_devices, which will remove all the children. Under some circumstances it is useful to remove only a subset of the child devices. For example if some additional clean up is required between removal of certain child devices. To accomplish this a level field is added to mfd_cell, the normal mfd_remove_devices is modified to not remove devices that are set to a higher level and a corresponding mfd_remove_devices_late function is added to remove those children. See further discussion at: https://lore.kernel.org/lkml/20200616075834.GF2608702@dell/Suggested-by:
-
Xu Wang authored
Simplify the return expression. Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Signed-off-by:
-
Colin Ian King authored
The variable current_bits is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Andreas Kemnade authored
Battery status changes dynamically, so the corresponding registers need to be considered volatile. Affected registers are: - fuel gauge - battery status - battery interrupt Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Signed-off-by:
-
Randy Dunlap authored
Drop the repeated word "in" in a comment. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Randy Dunlap authored
Drop the repeated word "that" in a comment. Signed-off-by:
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
-
Andreas Kemnade authored
The restart handler is executed during the shutdown phase which is atomic/irq-less. The i2c framework supports atomic transfers since commit 63b96983 ("i2c: core: introduce callbacks for atomic transfers") to address this use case. Using i2c regmap in that situation is not allowed: [ 165.177465] [ BUG: Invalid wait context ] [ 165.181479] 5.8.0-rc3-00003-g0e9088558027-dirty #11 Not tainted [ 165.187400] ----------------------------- [ 165.191410] systemd-shutdow/1 is trying to lock: [ 165.196030] d85b4438 (rn5t618:170:(&rn5t618_regmap_config)->lock){+.+.}-{3:3}, at: regmap_update_bits_base+0x30/0x70 [ 165.206573] other info that might help us debug this: [ 165.211625] context-{4:4} [ 165.214248] 2 locks held by systemd-shutdow/1: [ 165.218691] #0: c131c47c (system_transition_mutex){+.+.}-{3:3}, at: __do_sys_reboot+0x90/0x204 [ 165.227405] #1: c131efb4 (rcu_read_lock){....}-{1:2}, at: __atomic_notifier_call_chain+0x0/0x118 [ 165.236288] stack backtrace: [ 165.239174] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.8.0-rc3-00003-g0e9088558027-dirty #11 [ 165.248220] Hardware name: Freescale i.MX6 SoloLite (Device Tree) [ 165.254330] [<c0112110>] (unwind_backtrace) from [<c010bfa0>] (show_stack+0x10/0x14) [ 165.262084] [<c010bfa0>] (show_stack) from [<c058093c>] (dump_stack+0xe8/0x120) [ 165.269407] [<c058093c>] (dump_stack) from [<c01835a4>] (__lock_acquire+0x81c/0x2ca0) [ 165.277246] [<c01835a4>] (__lock_acquire) from [<c0186344>] (lock_acquire+0xe4/0x490) [ 165.285090] [<c0186344>] (lock_acquire) from [<c0c98638>] (__mutex_lock+0x74/0x954) [ 165.292756] [<c0c98638>] (__mutex_lock) from [<c0c98f34>] (mutex_lock_nested+0x1c/0x24) [ 165.300769] [<c0c98f34>] (mutex_lock_nested) from [<c07593ec>] (regmap_update_bits_base+0x30/0x70) [ 165.309741] [<c07593ec>] (regmap_update_bits_base) from [<c076b838>] (rn5t618_trigger_poweroff_sequence+0x34/0x64) [ 165.320097] [<c076b838>] (rn5t618_trigger_poweroff_sequence) from [<c076b874>] (rn5t618_restart+0xc/0x2c) [ 165.329669] [<c076b874>] (rn5t618_restart) from [<c01514f8>] (notifier_call_chain+0x48/0x80) [ 165.338113] [<c01514f8>] (notifier_call_chain) from [<c01516a8>] (__atomic_notifier_call_chain+0x70/0x118) [ 165.347770] [<c01516a8>] (__atomic_notifier_call_chain) from [<c0151768>] (atomic_notifier_call_chain+0x18/0x20) [ 165.357949] [<c0151768>] (atomic_notifier_call_chain) from [<c010a828>] (machine_restart+0x68/0x80) [ 165.367001] [<c010a828>] (machine_restart) from [<c0153224>] (__do_sys_reboot+0x11c/0x204) [ 165.375272] [<c0153224>] (__do_sys_reboot) from [<c0100080>] (ret_fast_syscall+0x0/0x28) [ 165.383364] Exception stack(0xd80a5fa8 to 0xd80a5ff0) [ 165.388420] 5fa0: 00406948 00000000 fee1dead 28121969 01234567 73299b00 [ 165.396602] 5fc0: 00406948 00000000 00000000 00000058 be91abc8 00000000 be91ab60 004056f8 [ 165.404781] 5fe0: 00000058 be91aabc b6ed4d45 b6e56746 Signed-off-by:
-
Stephen Rothwell authored
drivers/mfd/kempld-core.c: In function 'kempld_register_cells_generic': drivers/mfd/kempld-core.c:105:13: error: assignment of read-only location 'devs[i++]' 105 | devs[i++] = kempld_devs[KEMPLD_I2C]; | ^ drivers/mfd/kempld-core.c:108:13: error: assignment of read-only location 'devs[i++]' 108 | devs[i++] = kempld_devs[KEMPLD_WDT]; | ^ drivers/mfd/kempld-core.c:111:13: error: assignment of read-only location 'devs[i++]' 111 | devs[i++] = kempld_devs[KEMPLD_GPIO]; | ^ drivers/mfd/kempld-core.c:114:13: error: assignment of read-only location 'devs[i++]' 114 | devs[i++] = kempld_devs[KEMPLD_UART]; | ^ Fixes: e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Signed-off-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Frank Lee authored
The AXP803 can be used both using the RSB proprietary bus, or a more traditional I2C bus. Let's add that possibility. Signed-off-by:
Frank Lee <frank@allwinnertech.com> Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Adam Thomson authored
This update adds new regmap tables to support the latest DA silicon which will automatically be selected based on the chip and variant information read from the device. Signed-off-by:
-
Adam Thomson authored
The current implementation performs checking in the i2c_probe() function of the variant_code but does this immediately after the containing struct has been initialised as all zero. This means the check for variant code will always default to using the BB tables and will never select AD. The variant code is subsequently set by device_init() and later used by the RTC so really it's a little fortunate this mismatch works. This update adds raw I2C read access functionality to read the chip and variant/revision information (common to all revisions) so that it can subsequently correctly choose the proper regmap tables for real initialisation. Signed-off-by:
-
Fabio Estevam authored
Remove the I2C unit name to fix the following build warning with 'make dt_binding_check': Warning (unit_address_vs_reg): /example-0/i2c@0: node has a unit name, but no reg or ranges property Signed-off-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
-
Roger Quadros authored
Add DT binding schema for J721e system controller. Signed-off-by:
Roger Quadros <rogerq@ti.com> Reviewed-by:
-
Tony Lindgren authored
Otherwise we get spammed with errors on resume after rtcwake: cpcap-core spi0.0: Failed to read IRQ status: -108 Note that rtcwake is still capable of waking up the system with this patch. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Michael Walle authored
This MFD driver has no user. The keypad driver of this device never made it into the kernel. Therefore, this driver is useless. Remove it. Signed-off-by:
Michael Walle <michael@walle.cc> Cc: Sourav Poddar <sourav.poddar@ti.com> Signed-off-by:
-
Lee Jones authored
Extend current list of helpers to provide support for parent drivers wishing to match specific child devices to particular OF nodes. Signed-off-by: -
Lee Jones authored
Remove unnecessary '\'s and leading tabs. This will help to clean-up future diffs when subsequent changes are made. Hint: The aforementioned changes follow this patch. Signed-off-by: -
Lee Jones authored
Currently, when a child platform device (sometimes referred to as a sub-device) is registered via the Multi-Functional Device (MFD) API, the framework attempts to match the newly registered platform device with its associated Device Tree (OF) node. Until now, the device has been allocated the first node found with an identical OF compatible string. Unfortunately, if there are, say for example '3' devices which are to be handled by the same driver and therefore have the same compatible string, each of them will be allocated a pointer to the *first* node. An example Device Tree entry might look like this: mfd_of_test { compatible = "mfd,of-test-parent"; #address-cells = <0x02>; #size-cells = <0x02>; child@aaaaaaaaaaaaaaaa { compatible = "mfd,of-test-child"; reg = <0xaaaaaaaa 0xaaaaaaaa 0 0x11>, <0xbbbbbbbb 0xbbbbbbbb 0 0x22>; }; child@cccccccc { compatible = "mfd,of-test-child"; reg = <0x00000000 0xcccccccc 0 0x33>; }; child@dddddddd00000000 { compatible = "mfd,of-test-child"; reg = <0xdddddddd 0x00000000 0 0x44>; }; }; When used with example sub-device registration like this: static const struct mfd_cell mfd_of_test_cell[] = { OF_MFD_CELL("mfd-of-test-child", NULL, NULL, 0, 0, "mfd,of-test-child"), OF_MFD_CELL("mfd-of-test-child", NULL, NULL, 0, 1, "mfd,of-test-child"), OF_MFD_CELL("mfd-of-test-child", NULL, NULL, 0, 2, "mfd,of-test-child") }; ... the current implementation will result in all devices being allocated the first OF node found containing a matching compatible string: [0.712511] mfd-of-test-child mfd-of-test-child.0: Probing platform device: 0 [0.712710] mfd-of-test-child mfd-of-test-child.0: Using OF node: child@aaaaaaaaaaaaaaaa [0.713033] mfd-of-test-child mfd-of-test-child.1: Probing platform device: 1 [0.713381] mfd-of-test-child mfd-of-test-child.1: Using OF node: child@aaaaaaaaaaaaaaaa [0.713691] mfd-of-test-child mfd-of-test-child.2: Probing platform device: 2 [0.713889] mfd-of-test-child mfd-of-test-child.2: Using OF node: child@aaaaaaaaaaaaaaaa After this patch each device will be allocated a unique OF node: [0.712511] mfd-of-test-child mfd-of-test-child.0: Probing platform device: 0 [0.712710] mfd-of-test-child mfd-of-test-child.0: Using OF node: child@aaaaaaaaaaaaaaaa [0.713033] mfd-of-test-child mfd-of-test-child.1: Probing platform device: 1 [0.713381] mfd-of-test-child mfd-of-test-child.1: Using OF node: child@cccccccc [0.713691] mfd-of-test-child mfd-of-test-child.2: Probing platform device: 2 [0.713889] mfd-of-test-child mfd-of-test-child.2: Using OF node: child@dddddddd00000000 Which is fine if all OF nodes are identical. However if we wish to apply an attribute to particular device, we really need to ensure the correct OF node will be associated with the device containing the correct address. We accomplish this by matching the device's address expressed in DT with one provided during sub-device registration. Like this: static const struct mfd_cell mfd_of_test_cell[] = { OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 1, "mfd,of-test-child", 0xdddddddd00000000), OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 2, "mfd,of-test-child", 0xaaaaaaaaaaaaaaaa), OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 3, "mfd,of-test-child", 0x00000000cccccccc) }; This will ensure a specific device (designated here using the platform_ids; 1, 2 and 3) is matched with a particular OF node: [0.712511] mfd-of-test-child mfd-of-test-child.0: Probing platform device: 0 [0.712710] mfd-of-test-child mfd-of-test-child.0: Using OF node: child@dddddddd00000000 [0.713033] mfd-of-test-child mfd-of-test-child.1: Probing platform device: 1 [0.713381] mfd-of-test-child mfd-of-test-child.1: Using OF node: child@aaaaaaaaaaaaaaaa [0.713691] mfd-of-test-child mfd-of-test-child.2: Probing platform device: 2 [0.713889] mfd-of-test-child mfd-of-test-child.2: Using OF node: child@cccccccc This implementation is still not infallible, hence the mention of "best effort" in the commit subject. Since we have not *insisted* on the existence of 'reg' properties (in some scenarios they just do not make sense) and no device currently uses the new 'of_reg' attribute, we have to make an on-the-fly judgement call whether to associate the OF node anyway. Which we do in cases where parent drivers haven't specified a particular OF node to match to. So there is a *slight* possibility of the following result (note: the implementation here is convoluted, but it shows you one means by which this process can still break): /* * First entry will match to the first OF node with matching compatible * Second will fail, since the first took its OF node and is no longer available * Third will succeed */ static const struct mfd_cell mfd_of_test_cell[] = { OF_MFD_CELL("mfd-of-test-child", NULL, NULL, 0, 1, "mfd,of-test-child"), OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 2, "mfd,of-test-child", 0xaaaaaaaaaaaaaaaa), OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 3, "mfd,of-test-child", 0x00000000cccccccc) }; The result: [0.753869] mfd-of-test-parent mfd_of_test: Registering 3 devices [0.756597] mfd-of-test-child: Failed to locate of_node [id: 2] [0.759999] mfd-of-test-child mfd-of-test-child.1: Probing platform device: 1 [0.760314] mfd-of-test-child mfd-of-test-child.1: Using OF node: child@aaaaaaaaaaaaaaaa [0.760908] mfd-of-test-child mfd-of-test-child.2: Probing platform device: 2 [0.761183] mfd-of-test-child mfd-of-test-child.2: No OF node associated with this device [0.761621] mfd-of-test-child mfd-of-test-child.3: Probing platform device: 3 [0.761899] mfd-of-test-child mfd-of-test-child.3: Using OF node: child@cccccccc We could code around this with some pre-parsing semantics, but the added complexity required to cover each and every corner-case is not justified. Merely patching the current failing (via this patch) is already working with some pretty small corner-cases. Other issues should be patched in the parent drivers which can be achieved simply by implementing OF_MFD_CELL_REG(). Signed-off-by:
-
- 14 Jul, 2020 1 commit
-
-
Ikjoon Jang authored
Convert the ChromeOS EC bindings to json-schema. Signed-off-by:
Ikjoon Jang <ikjn@chromium.org> Reviewed-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
- 07 Jul, 2020 1 commit
-
-
Lee Jones authored
Since ACPI_PTR() is used to NULLify the value when !CONFIG_ACPI, struct axp20x_i2c_acpi_match becomes defined by unused. This squashes the current W=1 kernel builds warning: drivers/mfd/axp20x-i2c.c:82:36: warning: ‘axp20x_i2c_acpi_match’ defined but not used [-Wunused-const-variable=] Cc: Chen-Yu Tsai <wens@csie.org> Cc: Carlo Caione <carlo@caione.org> Signed-off-by:
-
- 06 Jul, 2020 16 commits
-
-
Lee Jones authored
'i / pdata->num_irqs' always equates to 0 and 'BIT(i % pdata->num_irqs)' always ends up being BIT(i) here, so make that clearer in the code. If the code base needs to support more than 32 IRQs in the future, this will have to be reworked, but lets just keep it simple for as long as we can. This fixes the following W=1 warning: drivers/mfd/sprd-sc27xx-spi.c:255 sprd_pmic_probe() debug: sval_binop_unsigned: divide by zero Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Suggested-by:
Baolin Wang <baolin.wang7@gmail.com> Signed-off-by:
-
Lee Jones authored
Argument 'received' was incorrectly named by its struct type 'completion' instead of its name. Fixes the following W=1 warning: drivers/mfd/rave-sp.c:107: warning: Function parameter or member 'received' not described in 'rave_sp_reply' Cc: Andrey Vostrikov <andrey.vostrikov@cogentembedded.com> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: -
Lee Jones authored
Kerneldoc syntax is used, but not complete. Descriptions are required for all arguments. Fixes the following W=1 build warning: drivers/mfd/si476x-cmd.c:907: warning: Function parameter or member 'report' not described in 'si476x_core_cmd_fm_rds_status' Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: -
Lee Jones authored
4 of the old arguments were grouped and moved into a struct which is now passed as a pointer instead of the arguments themselves. However, whoever carried out this work forgot to update the function's kerneldoc header. Fixes the following W=1 warnings: drivers/mfd/si476x-cmd.c:746: warning: Function parameter or member 'rsqargs' not described in 'si476x_core_cmd_am_rsq_s drivers/mfd/si476x-cmd.c:746: warning: Excess function parameter 'rsqack' description in 'si476x_core_cmd_am_rsq_status' drivers/mfd/si476x-cmd.c:746: warning: Excess function parameter 'attune' description in 'si476x_core_cmd_am_rsq_status' drivers/mfd/si476x-cmd.c:746: warning: Excess function parameter 'cancel' description in 'si476x_core_cmd_am_rsq_status' drivers/mfd/si476x-cmd.c:746: warning: Excess function parameter 'stcack' description in 'si476x_core_cmd_am_rsq_status' Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: -
Lee Jones authored
's/FALLTHROUG/FALLTHROUGH' Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: -
Lee Jones authored
Kerneldoc syntax is used, but not complete. Descriptions are required for all arguments. Fixes the following W=1 build warning: drivers/mfd/si476x-i2c.c:550: warning: Function parameter or member 'func' not described in 'si476x_core_fwver_to_revision' Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: -
Lee Jones authored
Kerneldoc validation gets confused if syntax isn't "@.*: ". Adding the missing colons squashes the following W=1 warnings: drivers/mfd/si476x-cmd.c:525: warning: Function parameter or member 'dout' not described in 'si476x_core_cmd_dig_audio_pin_c drivers/mfd/si476x-cmd.c:525: warning: Function parameter or member 'xout' not described in 'si476x_core_cmd_dig_audio_pin_c drivers/mfd/si476x-cmd.c:574: warning: Function parameter or member 'core' not described in 'si476x_core_cmd_zif_pin_cfg' drivers/mfd/si476x-cmd.c:574: warning: Function parameter or member 'iqclk' not described in 'si476x_core_cmd_zif_pin_cfg' drivers/mfd/si476x-cmd.c:574: warning: Function parameter or member 'iqfs' not described in 'si476x_core_cmd_zif_pin_cfg' drivers/mfd/si476x-cmd.c:574: warning: Function parameter or member 'iout' not described in 'si476x_core_cmd_zif_pin_cfg' drivers/mfd/si476x-cmd.c:574: warning: Function parameter or member 'qout' not described in 'si476x_core_cmd_zif_pin_cfg' drivers/mfd/si476x-i2c.c:550: warning: Function parameter or member 'func' not described in 'si476x_core_fwver_to_revision' drivers/mfd/si476x-cmd.c:631: warning: Function parameter or member 'core' not described in 'si476x_core_cmd_ic_link_gpo_ctl drivers/mfd/si476x-cmd.c:631: warning: Function parameter or member 'icin' not described in 'si476x_core_cmd_ic_link_gpo_ctl drivers/mfd/si476x-cmd.c:631: warning: Function parameter or member 'icip' not described in 'si476x_core_cmd_ic_link_gpo_ctl drivers/mfd/si476x-cmd.c:631: warning: Function parameter or member 'icon' not described in 'si476x_core_cmd_ic_link_gpo_ctl drivers/mfd/si476x-cmd.c:631: warning: Function parameter or member 'icop' not described in 'si476x_core_cmd_ic_link_gpo_ctl drivers/mfd/si476x-cmd.c:662: warning: Function parameter or member 'core' not described in 'si476x_core_cmd_ana_audio_pin_c drivers/mfd/si476x-cmd.c:662: warning: Function parameter or member 'lrout' not described in 'si476x_core_cmd_ana_audio_pin_ drivers/mfd/si476x-cmd.c:697: warning: Function parameter or member 'core' not described in 'si476x_core_cmd_intb_pin_cfg_a1 drivers/mfd/si476x-cmd.c:697: warning: Function parameter or member 'intb' not described in 'si476x_core_cmd_intb_pin_cfg_a1 drivers/mfd/si476x-cmd.c:697: warning: Function parameter or member 'a1' not described in 'si476x_core_cmd_intb_pin_cfg_a10' drivers/mfd/si476x-cmd.c:746: warning: Function parameter or member 'core' not described in 'si476x_core_cmd_am_rsq_status' drivers/mfd/si476x-cmd.c:746: warning: Function parameter or member 'rsqargs' not described in 'si476x_core_cmd_am_rsq_statu drivers/mfd/si476x-cmd.c:746: warning: Function parameter or member 'report' not described in 'si476x_core_cmd_am_rsq_status drivers/mfd/si476x-cmd.c:878: warning: Function parameter or member 'core' not described in 'si476x_core_cmd_fm_seek_start' drivers/mfd/si476x-cmd.c:878: warning: Function parameter or member 'seekup' not described in 'si476x_core_cmd_fm_seek_start drivers/mfd/si476x-cmd.c:878: warning: Function parameter or member 'wrap' not described in 'si476x_core_cmd_fm_seek_start' drivers/mfd/si476x-cmd.c:907: warning: Function parameter or member 'core' not described in 'si476x_core_cmd_fm_rds_status' drivers/mfd/si476x-cmd.c:907: warning: Function parameter or member 'status_only' not described in 'si476x_core_cmd_fm_rds_s drivers/mfd/si476x-cmd.c:907: warning: Function parameter or member 'mtfifo' not described in 'si476x_core_cmd_fm_rds_status drivers/mfd/si476x-cmd.c:907: warning: Function parameter or member 'intack' not described in 'si476x_core_cmd_fm_rds_status drivers/mfd/si476x-cmd.c:907: warning: Function parameter or member 'report' not described in 'si476x_core_cmd_fm_rds_status drivers/mfd/si476x-cmd.c:1052: warning: Function parameter or member 'core' not described in 'si476x_core_cmd_am_seek_start' drivers/mfd/si476x-cmd.c:1052: warning: Function parameter or member 'seekup' not described in 'si476x_core_cmd_am_seek_star drivers/mfd/si476x-cmd.c:1052: warning: Function parameter or member 'wrap' not described in 'si476x_core_cmd_am_seek_start' Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: -
Lee Jones authored
si476x_core_send_command()'s 5th argument has never been called response. This change must have occurred prior to the driver being Mainlined. We're also taking the opportunity to bring the first description back into line, making my OCD happy! This fixes the following W=1 warning(s): drivers/mfd/si476x-cmd.c:264: warning: Function parameter or member 'resp' not described in 'si476x_core_send_command drivers/mfd/si476x-cmd.c:264: warning: Excess function parameter 'response' description in 'si476x_core_send_command' Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: -
Lee Jones authored
'status' hasn't been checked since 2008. It's probably safe to remove it. Fixes W=1 warning: drivers/mfd/tps65010.c:407:7: warning: variable ‘status’ set but not used [-Wunused-but-set-variable] 407 | int status; | ^~~~~~ Signed-off-by: -
Lee Jones authored
Kerneldoc validation gets confused if syntax isn't "@.*: ". Adding the missing colons squashes the following W=1 warnings: drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'dev' not described in 'ab3100_otp' drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'locked' not described in 'ab3100_otp' drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'freq' not described in 'ab3100_otp' drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'paf' not described in 'ab3100_otp' drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'imeich' not described in 'ab3100_otp' drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'cid' not described in 'ab3100_otp' drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'tac' not described in 'ab3100_otp' drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'fac' not described in 'ab3100_otp' drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'svn' not described in 'ab3100_otp' drivers/mfd/ab3100-otp.c:60: warning: Function parameter or member 'debugfs' not described in 'ab3100_otp' Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: -
Lee Jones authored
The kerneldocs for both tps65217_reg_write() and tps65217_update_bits() describe their first arguments as 'tps65217', when in reality these are simply called 'tps'. Fixes the following W=1 warnings: drivers/mfd/tps65217.c:215: warning: Function parameter or member 'tps' not described in 'tps65217_reg_write' drivers/mfd/tps65217.c:215: warning: Excess function parameter 'tps65217' description in 'tps65217_reg_write' drivers/mfd/tps65217.c:261: warning: Function parameter or member 'tps' not described in 'tps65217_update_bits' drivers/mfd/tps65217.c:261: warning: Excess function parameter 'tps65217' description in 'tps65217_update_bits' Cc: Tony Lindgren <tony@atomide.com> Cc: AnilKumar Ch <anilkumar@ti.com> Cc: linux-omap@vger.kernel.org Signed-off-by: -
Lee Jones authored
The kerneldocs for both tps65218_reg_write() and tps65218_update_bits() describe their first arguments as 'tps65218', when in reality these are simply called 'tps'. Fixes the following W=1 warnings: drivers/mfd/tps65218.c:58: warning: Function parameter or member 'tps' not described in 'tps65218_reg_write' drivers/mfd/tps65218.c:58: warning: Excess function parameter 'tps65218' description in 'tps65218_reg_write' drivers/mfd/tps65218.c:90: warning: Function parameter or member 'tps' not described in 'tps65218_update_bits' drivers/mfd/tps65218.c:90: warning: Excess function parameter 'tps65218' description in 'tps65218_update_bits' Cc: Tony Lindgren <tony@atomide.com> Cc: J Keerthy <j-keerthy@ti.com> Cc: linux-omap@vger.kernel.org Signed-off-by: -
Lee Jones authored
Kerneldoc expects kernel structures to be prefixed with 'struct'. Fixes the following W=1 level warnings: drivers/mfd/cros_ec_dev.c:32: warning: cannot understand function prototype: 'struct cros_feature_to_name ' drivers/mfd/cros_ec_dev.c:44: warning: cannot understand function prototype: 'struct cros_feature_to_cells ' Cc: Benson Leung <bleung@chromium.org> Cc: Guenter Roeck <groeck@chromium.org> Cc: Bill Richardson <wfrichar@chromium.org> Signed-off-by:
-
Lee Jones authored
Kerneldoc syntax is used, but not complete. Arg descriptions are required. Fixes the following W=1 build warnings: drivers/mfd/altera-sysmgr.c:95: warning: Function parameter or member 'np' not described in 'altr_sysmgr_regmap_lookup_by_phandle' drivers/mfd/altera-sysmgr.c:95: warning: Function parameter or member 'property' not described in 'altr_sysmgr_regmap_lookup_by_phandle' Cc: Thor Thayer <thor.thayer@linux.intel.com> Signed-off-by: -
Lee Jones authored
Kerneldoc valication gets confused if syntax isn't "@.*: ". Adding the missing colons squashes the following W=1 warnings: drivers/mfd/atmel-smc.c:247: warning: Function parameter or member 'conf' not described in 'atmel_smc_cs_conf_apply' drivers/mfd/atmel-smc.c:268: warning: Function parameter or member 'conf' not described in 'atmel_hsmc_cs_conf_apply' Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: -
Lee Jones authored
Kerneldoc syntax is used, but not complete. Arg descriptions required. Prevents warnings like: drivers/mfd/omap-usb-tll.c:204: warning: Function parameter or member 'pdev' not described in 'usbtll_omap_probe Cc: Tony Lindgren <tony@atomide.com> Cc: Keshava Munegowda <keshava_mgowda@ti.com> Cc: Roger Quadros <rogerq@ti.com> Cc: linux-omap@vger.kernel.org Signed-off-by:
-
