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 <lee.jones@linaro.org>
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: Lee Jones <lee.jones@linaro.org>
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: Lee Jones <lee.jones@linaro.org>
'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 <lee.jones@linaro.org>
Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
'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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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: Lee Jones <lee.jones@linaro.org>
Kerneldoc syntax is used, but not complete. Arg descriptions required.
Prevents warnings like:
drivers/mfd/omap-usb-host.c:531: warning: Function parameter or member 'pdev' not described in 'usbhs_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: Lee Jones <lee.jones@linaro.org>
Kerneldoc is for documenting function arguments and return values.
Prevents warnings like:
drivers/mfd/omap-usb-host.c:128: warning: cannot understand function prototype: 'const char * const port_modes[] = '
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: Lee Jones <lee.jones@linaro.org>
Not only is the current header incorrect, the isn't actually a
need to document the ubiquitous platform probe call.
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Each function parameter should be documented in kerneldoc format.
Squashes the following W=1 warnings:
drivers/mfd/db8500-prcmu.c:2281: warning: Function parameter or member 'reset_code' not described in 'db8500_prcmu_system_reset'
drivers/mfd/db8500-prcmu.c:3012: warning: Function parameter or member 'pdev' not described in 'db8500_prcmu_probe'
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Each function parameter should be documented in kerneldoc format.
Squashes the following W=1 warnings:
drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'dev' not described in 'devm_mfd_add_devices'
drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'id' not described in 'devm_mfd_add_devices'
drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'cells' not described in 'devm_mfd_add_devices'
drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'n_devs' not described in 'devm_mfd_add_devices'
drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'mem_base' not described in 'devm_mfd_add_devices'
drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'irq_base' not described in 'devm_mfd_add_devices'
drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'domain' not described in 'devm_mfd_add_devices'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Kerneldoc syntax is used, but not complete. Descriptions required.
Prevents warnings like:
drivers/mfd/wm8350-core.c:136: warning: Function parameter or member 'wm8350' not described in 'wm8350_reg_lock'
drivers/mfd/wm8350-core.c:165: warning: Function parameter or member 'wm8350' not described in 'wm8350_reg_unlock'
Cc: patches@opensource.cirrus.com
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Kerneldoc syntax is used, but not complete. Descriptions required.
Prevents warnings like:
drivers/mfd/wm831x-core.c:119: warning: Function parameter or member 'wm831x' not described in 'wm831x_reg_lock'
drivers/mfd/wm831x-core.c:145: warning: Function parameter or member 'wm831x' not described in 'wm831x_reg_unlock'
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: patches@opensource.cirrus.com
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Kerneldoc syntax is used, but not complete. Descriptions required.
Prevents warnings like:
drivers/mfd/wm8400-core.c:113: warning: Function parameter or member 'wm8400' not described in 'wm8400_reset_codec_reg_cache'
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: patches@opensource.cirrus.com
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Kerneldoc is for documenting function arguments and return values.
Prevents warnings like:
drivers/mfd/tc3589x.c:32: warning: Enum value 'TC3589X_TC35890' not described in enum 'tc3589x_version'
drivers/mfd/tc3589x.c:32: warning: Enum value 'TC3589X_TC35892' not described in enum 'tc3589x_version'
drivers/mfd/tc3589x.c:32: warning: Enum value 'TC3589X_TC35893' not described in enum 'tc3589x_version'
drivers/mfd/tc3589x.c:32: warning: Enum value 'TC3589X_TC35894' not described in enum 'tc3589x_version'
drivers/mfd/tc3589x.c:32: warning: Enum value 'TC3589X_TC35895' not described in enum 'tc3589x_version'
drivers/mfd/tc3589x.c:32: warning: Enum value 'TC3589X_TC35896' not described in enum 'tc3589x_version'
drivers/mfd/tc3589x.c:32: warning: Enum value 'TC3589X_UNKNOWN' not described in enum 'tc3589x_version'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Smatch reports:
drivers/mfd/ab8500-debugfs.c:1804:20: error: incompatible types in comparison expression (different type sizes):
drivers/mfd/ab8500-debugfs.c:1804:20: unsigned int *
drivers/mfd/ab8500-debugfs.c:1804:20: unsigned long *
This is due to mixed types being compared in a min() comparison. Fix
this by treating values as signed and casting them to the same type
as the receiving variable.
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Smatch reports:
drivers/mfd/ab3100-core.c:501:20: error: incompatible types in comparison expression (different type sizes):
drivers/mfd/ab3100-core.c:501:20: unsigned int *
drivers/mfd/ab3100-core.c:501:20: unsigned long *
drivers/mfd/ab8500-debugfs.c:1804:20: error: incompatible types in comparison expression (different type sizes):
drivers/mfd/ab8500-debugfs.c:1804:20: unsigned int *
drivers/mfd/ab8500-debugfs.c:1804:20: unsigned long *
Since the second min() argument can be less than 0 a signed
variable is required for assignment. However, the non-sized
type size_t is passed in from the userspace handlers. In order
to firstly compare, then assign the smallest value, we firstly
need to cast them both to the same as the receiving size_t typed
variable.
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Sparse reports:
drivers/mfd/sprd-sc27xx-spi.c:59:23: warning: symbol 'sprd_pmic_detect_charger_type' was not declared. Should it be static?
... due to a missing header file.
Cc: Orson Zhai <orsonzhai@gmail.com>
Cc: Chunyan Zhang <zhang.lyra@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Sparse reports:
drivers/mfd/altera-sysmgr.c:150:30: warning: incorrect type in assignment (different address spaces)
drivers/mfd/altera-sysmgr.c:150:30: expected unsigned int [usertype] *base
drivers/mfd/altera-sysmgr.c:150:30: got void [noderef] <asn:2> *
drivers/mfd/altera-sysmgr.c:156:26: warning: incorrect type in argument 3 (different address spaces)
drivers/mfd/altera-sysmgr.c:156:26: expected void [noderef] <asn:2> *regs
drivers/mfd/altera-sysmgr.c:156:26: got unsigned int [usertype] *base
It appears as though the driver data property 'resource_size_t *base'
was being used to store 2 different types of addresses (physical and
IO-mapped) under a single declared type.
Fortunately, no value is recalled from the driver data entry, so it
can be easily omitted. Instead we can use the value obtained directly
from the platform resource to pass through Regmap into the call-backs
to be used for the SMCC call and use a local dedicated __iomem
variable for IO-remapping.
Cc: Thor Thayer <thor.thayer@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Silences Sparse warning:
drivers/mfd/twl4030-irq.c:485:26: warning: incorrect type in assignment (different base types)
drivers/mfd/twl4030-irq.c:485:26: expected unsigned int [usertype] word
drivers/mfd/twl4030-irq.c:485:26: got restricted __le32 [usertype]
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kai Svahn <kai.svahn@nokia.com>
Cc: Syed Khasim <x0khasim@ti.com>
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Expand the control-bank accessors that were implemented using macros.
This allows the definitions of these exported functions to be found more
easily and specifically avoids a W=1 compiler warning due to the
redundant brightness sanity check:
drivers/mfd/lm3533-ctrlbank.c: In function 'lm3533_ctrlbank_set_brightness':
drivers/mfd/lm3533-ctrlbank.c:98:10: warning: comparison is always false due to limited range of data type [-Wtype-limits]
98 | if (val > LM3533_##_NAME##_MAX) \
| ^
drivers/mfd/lm3533-ctrlbank.c:125:1: note: in expansion of macro 'lm3533_ctrlbank_set'
125 | lm3533_ctrlbank_set(brightness, BRIGHTNESS);
| ^~~~~~~~~~~~~~~~~~~
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Intel Tiger Lake PCH-H has the same LPSS than Intel Broxton.
Add the new IDs to the list of supported devices.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
SC27XX-SPI added subdevices according to a pre-defined mfd_cell array,
no matter these devices were really included on board. In this patch,
switch to use devm_of_platform_populate() for adding sub-devices which
are defined in devicetree.
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This Microcontroller is present on the Khadas VIM1, VIM2, VIM3 and Edge
boards.
It has multiple boot control features like password check, power-on
options, power-off control and system FAN control on recent boards.
This implements a very basic MFD driver with the fan control and User
NVMEM cells.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The mfd_cell structures inconsistently use commas on single entries in
the table, make this consistent by always using a comma. Also remove an
extra blank line.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Whilst it doesn't matter if the internal 32k clock register settings
are cleaned up on exit, as the part will be turned off losing any
settings, hence the driver hasn't historially bothered. The external
clock should however be cleaned up, as it could cause clocks to be
left on, and will at best generate a warning on unbind.
Add clean up on both the probe error path and unbind for the 32k
clock.
Fixes: cdd8da8cc6 ("mfd: arizona: Add gating of external MCLKn clocks")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
BUG_ON macros are generally frowned upon when the issue isn't super
critical, the kernel can certainly carry on with the 32k clock on the
CODEC in a bad state so change the BUG_ON to a WARN_ON.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Intel Emmitsburg PCH has the same LPSS than Intel Ice Lake.
Add the new IDs to the list of supported devices.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Because stm32-lptimer need to write in registers in interrupt context
enable regmap fast_io to use a spin_lock to protect registers access
rather than a mutex.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Since commit 84af7a6194 ("checkpatch: kconfig: prefer 'help' over
'---help---'"), the number of '---help---' has been gradually
decreasing, but there are still more than 2400 instances.
This commit finishes the conversion. While I touched the lines,
I also fixed the indentation.
There are a variety of indentation styles found.
a) 4 spaces + '---help---'
b) 7 spaces + '---help---'
c) 8 spaces + '---help---'
d) 1 space + 1 tab + '---help---'
e) 1 tab + '---help---' (correct indentation)
f) 1 tab + 1 space + '---help---'
g) 1 tab + 2 spaces + '---help---'
In order to convert all of them to 1 tab + 'help', I ran the
following commend:
$ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Core changes:
- A new GPIO aggregator driver has been merged: this can
join a few select GPIO lines into a new aggregated GPIO
chip. This can be used for security: a process can be
granted access to only these lines, for example for
industrial control. Another way to use this is to
reexpose certain select lines to a virtual machine or
container.
- Warn if the gpio-line-names is too long in he DT parser
core.
- GPIO lines can now be looked up by line name in addition
to being looked up by offset.
New drivers:
- A new generic regmap GPIO driver has been merged. Too
many regmap drivers are starting to look like each other
so we need to create some common ground and try to move
drivers over to using that.
- The F7188X driver now supports F81865.
Driver improvements:
- Large improvements to the PCA953x expander, get multiple lines
and several cleanups.
- Large improvements to the DesignWare DWAPB driver, and Sergey
Semin has volunteered to maintain it.
- PL061 can now be built as a module, this is part of a bigger
effort to make the ARM platforms more modular.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl7ZarsACgkQQRCzN7AZ
XXNRERAAvb/8YZX8yzfWqqKZ+aXxBOzn5LsbS15QjJz9W22wAZNhjNEHAtzd+xNJ
BiyDt+BQLGqIr2aCKglVFOOYfa8PhTjrVA40ujRFUs3d8q8gr/RFpfGN3/w36h0W
e3+QCHqe27Sk07wCB3RH7hzGcKhEUUt+A5sI0uX/nt9obx8IxdVPkafBYqCfdfWw
qv9T/MU75ZYeLURg24AkgZR069gQeiDAEKVa8lYh9qKBhircFzBxM6Bg9Efn8tst
E+6XIXNREslXBq5wtAosXI/t25ZpYtzDvkM5+/lm1jQyjMEh9wJyjmgu7tcRRZRK
xxxOcUHybDJaCFogkA5iOLzyfcUbGZM/i5wQkUE3SPACypGfncjkYZPdY6Smljd1
SfBfl48xch2WW12f1/P04VwSVDNxNe9/RUqapZ5ZQfd2DJwyiZM6p+S85rrFKJse
BvixFpGMY3J5h/lZUoaF93JaaQiWh2RK6WnsBvMVn2P9+WyPnwdUL2EX2RrYvdMR
iH3jmRzlSeVQnest5c1k+i05O3D0fq3gJ+qvzT5gqxbFdRm6HZEhJNiVT56Y1V4n
30FJMbXg8mddxLvl7b1Hfi5E7PLFOP9Ygz7bHxAfogROGpWMMGgAlynxcSjqUesg
YWoRPl0XmtMcsvVNJvLM/B3+Gxh78CsMzo4Nwh9FtgUMOG6B0Xw=
=B5OK
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for the v5.8 kernel cycle.
Core changes:
- A new GPIO aggregator driver has been merged: this can join a few
select GPIO lines into a new aggregated GPIO chip. This can be used
for security: a process can be granted access to only these lines,
for example for industrial control. Another way to use this is to
reexpose certain select lines to a virtual machine or container.
- Warn if the gpio-line-names is too long in he DT parser core.
- GPIO lines can now be looked up by line name in addition to being
looked up by offset.
New drivers:
- A new generic regmap GPIO driver has been merged. Too many regmap
drivers are starting to look like each other so we need to create
some common ground and try to move drivers over to using that.
- The F7188X driver now supports F81865.
Driver improvements:
- Large improvements to the PCA953x expander, get multiple lines and
several cleanups.
- Large improvements to the DesignWare DWAPB driver, and Sergey Semin
has volunteered to maintain it.
- PL061 can now be built as a module, this is part of a bigger effort
to make the ARM platforms more modular"
* tag 'gpio-v5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (77 commits)
gpio: pca953x: Drop unneeded ACPI_PTR()
MAINTAINERS: Add gpio regmap section
gpio: add a reusable generic gpio_chip using regmap
gpiolib: Introduce gpiochip_irqchip_add_domain()
gpio: gpiolib: Allow GPIO IRQs to lazy disable
gpiolib: Separate GPIO_GET_LINEINFO_WATCH_IOCTL conditional
gpio: rcar: Fix runtime PM imbalance on error
gpio: pca935x: Allow IRQ support for driver built as a module
gpio: pxa: Add COMPILE_TEST support
dt-bindings: gpio: Add renesas,em-gio bindings
MAINTAINERS: Fix file name for DesignWare GPIO DT schema
gpio: dwapb: Remove unneeded has_irq member in struct dwapb_port_property
gpio: dwapb: Don't use IRQ 0 as valid Linux interrupt
gpio: dwapb: avoid error message for optional IRQ
gpio: dwapb: Call acpi_gpiochip_free_interrupts() on GPIO chip de-registration
gpio: max730x: bring gpiochip_add_data after port config
MAINTAINERS: Add GPIO Aggregator section
docs: gpio: Add GPIO Aggregator documentation
gpio: Add GPIO Aggregator
gpiolib: Add support for GPIO lookup by line name
...
One new platform gets added, the Realtek RTD1195, which is an older
Cortex-a7 based relative of the RTD12xx chips that are already supported
in arch/arm64. The platform may also be extended to support running
32-bit kernels on those 64-bit chips for memory-constrained machines.
In the Renesas shmobile platform, we gain support for "RZ/G1H" or R8A7742,
an eight-core chip based on Cortex-A15 and Cortex-A7 cores, originally
released in 2016 as one of the last high-end 32-bit designs.
There is ongoing cleanup for the integrator, tegra, imx, and omap2
platforms, with integrator getting very close to the goal of having
zero code in arch/arm/, and omap2 moving more of the chip specifics
from old board code into device tree files.
The Versatile Express platform is made more modular, with built-in
drivers now becoming loadable modules. This is part of a greater effort
for the Android OS to have a common kernel binary for all platforms and
any platform specific code in loadable modules.
The PXA platform drops support for Compulab's pxa2xx boards that had
rather unusual flash and PCI drivers but no known users remaining.
All device drivers specific to those boards can now get removed as
well.
Across platforms, there is ongoing cleanup, with Geert and Rob
revisiting some a lot of Kconfig options.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAl7XvmAACgkQmmx57+YA
GNk4vRAAs3TxlwLAUk5dknAi+UstlviNPG/ys6mViFuLqktPyhkA/v6nFOBI5Ldf
8xAsaSk3+oAX3Dd7aTaudl5WMFWFtzT5xA4gEI7CBZrBaAL0BVns1JfnVxpPRIcF
B09Sb3wv7++E/+AxYcoVLWd5wkc9tlMesrIV5FPHHasOp3rRjVI0cExXnXzqJU8M
TbwrWEOczZNVAm2q4Eh1ttbuSIvPd3s4NMnI755MRSQ7u/rYFSPf6Ay8/eFTqx1e
0SMWHRmrGeP6yhLy7+Li0x0jsK3ReZ9SkLXp3iEZ9huKbBTHIPBUeBB1RMnCYGe+
M2OL+9ySSe9UI9sjvsLGPDAnJaZI/UDUOVhatZCTvYB7CZY5nYNrYp+heYFONWm6
Up3e1t2iGPbgs8/1y78a9YPxAdsW0iavRtjVUYb+nwX+savYZgSBATA1pZqLc317
5FAGmTh//OLKYBSjfAxu9H8aInJPZA595lUiPHEQujzZH5Xz0QNtv4dapeNL2I4g
LO20PMvuEgmwlwj/Npnwdl0UQK3ztoeR2upCrk91VwtNWGiOWTzCMT/OkYAAjKuo
QYMGu3UvbbTCHPsIdrUz8gZ2T3VnJoeE3ldny2QbNAtVdpH/F8htJcilrBbyv1vI
IKB1oogf5zfUwXVwZRxCfI9s5hELUlAKMGTtNcybzdsKpN5xtTo=
=gzCp
-----END PGP SIGNATURE-----
Merge tag 'arm-soc-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC updates from Arnd Bergmann:
"One new platform gets added, the Realtek RTD1195, which is an older
Cortex-a7 based relative of the RTD12xx chips that are already
supported in arch/arm64. The platform may also be extended to support
running 32-bit kernels on those 64-bit chips for memory-constrained
machines.
In the Renesas shmobile platform, we gain support for "RZ/G1H" or
R8A7742, an eight-core chip based on Cortex-A15 and Cortex-A7 cores,
originally released in 2016 as one of the last high-end 32-bit
designs.
There is ongoing cleanup for the integrator, tegra, imx, and omap2
platforms, with integrator getting very close to the goal of having
zero code in arch/arm/, and omap2 moving more of the chip specifics
from old board code into device tree files.
The Versatile Express platform is made more modular, with built-in
drivers now becoming loadable modules. This is part of a greater
effort for the Android OS to have a common kernel binary for all
platforms and any platform specific code in loadable modules.
The PXA platform drops support for Compulab's pxa2xx boards that had
rather unusual flash and PCI drivers but no known users remaining. All
device drivers specific to those boards can now get removed as well.
Across platforms, there is ongoing cleanup, with Geert and Rob
revisiting some a lot of Kconfig options"
* tag 'arm-soc-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (94 commits)
ARM: omap2: fix omap5_realtime_timer_init definition
ARM: zynq: Don't select CONFIG_ICST
ARM: OMAP2+: Fix regression for using local timer on non-SMP SoCs
clk: versatile: Fix kconfig dependency on COMMON_CLK_VERSATILE
ARM: davinci: fix build failure without I2C
power: reset: vexpress: fix build issue
power: vexpress: cleanup: use builtin_platform_driver
power: vexpress: add suppress_bind_attrs to true
Revert "ARM: vexpress: Don't select VEXPRESS_CONFIG"
MAINTAINERS: pxa: remove Compulab arm/pxa support
ARM: pxa: remove Compulab pxa2xx boards
bus: arm-integrator-lm: Fix return value check in integrator_ap_lm_probe()
soc: imx: move cpu code to drivers/soc/imx
ARM: imx: move cpu definitions into a header
ARM: imx: use device_initcall for imx_soc_device_init
ARM: imx: pcm037: make pcm970_sja1000_platform_data static
bus: ti-sysc: Timers no longer need legacy quirk handling
ARM: OMAP2+: Drop old timer code for dmtimer and 32k counter
ARM: dts: Configure system timers for omap2
ARM: dts: Configure system timers for ti81xx
...
Add MFD driver for mt6360 pmic chip include Battery Charger/
USB_PD/Flash, LED/RGB and LED/LDO/Buck
Signed-off-by: Gene Chen <gene_chen@richtek.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The MAX77620 doesn't support bulk writes, so make sure the regmap code
breaks bulk writes into multiple single-byte writes.
Note that this is mostly cosmetic because currently only the RTC sub-
driver uses bulk writes and the RTC driver ends up using a different
regmap on the MAX77620 anyway. However, it seems like a good idea to
make this change now in order to avoid running into issues if bulk
writes are ever used by other sub-drivers sometime down the road.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>