Skip to content
  1. Aug 18, 2020
    • Thierry Reding's avatar
      of: platform: Destroy child devices symmetrically · 70a29209
      Thierry Reding authored 
      

Iterate over child devices in reverse when unpopulating a platform
device to make this step symmetrical with the population step. This
fixes an issue in the Tegra DRM driver where upon module unload the
DPAUX controller tries to unregister an I2C controller but will end
up waiting indefinitely because one of the SOR devices is keeping a
reference to it. Since the SOR devices are instantiated after the
DPAUX devices, they would only be removed (and hence release their
reference to the I2C controller) after the DPAUX devices have been
removed.

While destroying the child devices in reverse order helps in this
situation, it isn't fully safe to do so either. An even better way
would be for the child devices to be reordered to match the probe
order, which would work irrespective of the instantiation order.

However, reordering by probe order would be fairly complicated and
doesn't fix any known issues, so we'll go with the simpler fix for
now.

Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200806153650.3883530-1-thierry.reding@gmail.com


Signed-off-by: default avatarRob Herring <robh@kernel.org>
      70a29209
  3. Aug 15, 2020
  5. Aug 13, 2020
    • Oleksandr Andrushchenko's avatar
      drm/xen-front: Pass dumb buffer data offset to the backend · 585c6ed7
      Oleksandr Andrushchenko authored 
      

While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.

Signed-off-by: default avatarOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: default avatarNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      585c6ed7
    • Oleksandr Andrushchenko's avatar
      drm/xen-front: Add YUYV to supported formats · 12957299
      Oleksandr Andrushchenko authored 
      

Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.

Signed-off-by: default avatarOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: default avatarNoralf Trønnes <noralf@tronnes.org>
Link: https://lore.kernel.org/r/20200813062113.11030-4-andr2000@gmail.com


Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      12957299
    • Oleksandr Andrushchenko's avatar
      drm/xen-front: Fix misused IS_ERR_OR_NULL checks · 14dee058
      Oleksandr Andrushchenko authored 
      

The patch c575b7ee: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:

	drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
	warn: passing zero to 'ERR_CAST'

drivers/gpu/drm/xen/xen_drm_front_gem.c
   133  struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
   134                                                  size_t size)
   135  {
   136          struct xen_gem_object *xen_obj;
   137
   138          xen_obj = gem_create(dev, size);
   139          if (IS_ERR_OR_NULL(xen_obj))
   140                  return ERR_CAST(xen_obj);

Fix this and the rest of misused places with IS_ERR_OR_NULL in the
driver.

Fixes:  c575b7ee: "drm/xen-front: Add support for Xen PV display frontend"

Signed-off-by: default avatarOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200813062113.11030-3-andr2000@gmail.com


Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      14dee058
    • Oleksandr Andrushchenko's avatar
      xen/gntdev: Fix dmabuf import with non-zero sgt offset · 5fa4e6f1
      Oleksandr Andrushchenko authored 
      

It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.

Fixes: bf8dc55b ("xen/gntdev: Implement dma-buf import functionality")

Signed-off-by: default avatarOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: default avatarJuergen Gross <jgross@suse.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200813062113.11030-2-andr2000@gmail.com


Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      5fa4e6f1
    • Suman Anna's avatar
      mfd: syscon: Use a unique name with regmap_config · e15d7f2b
      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: default avatarSuman Anna <s-anna@ti.com>
Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      e15d7f2b
    • Alexander A. Klimov's avatar
      mfd: Replace HTTP links with HTTPS ones · 4f4ed454
      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: default avatarAlexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      4f4ed454
    • Andy Shevchenko's avatar
      mfd: dln2: Run event handler loop under spinlock · 3d858942
      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: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      3d858942
    • Charles Keepax's avatar
      mfd: madera: Improve handling of regulator unbinding · 77b3ddab
      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: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      77b3ddab
    • Charles Keepax's avatar
      mfd: mfd-core: Add mechanism for removal of a subset of children · 114294d2
      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: default avatarLee Jones <lee.jones@linaro.org>
Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      114294d2
    • Xu Wang's avatar
      mfd: intel_soc_pmic_mrfld: Simplify the return expression of intel_scu_ipc_dev_iowrite8() · 4ee1d9dc
      Xu Wang authored 
      

Simplify the return expression.

Signed-off-by: default avatarXu Wang <vulab@iscas.ac.cn>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      4ee1d9dc
    • Colin Ian King's avatar
      mfd: max14577: Remove redundant initialization of variable current_bits · 1f0fa85c
      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: default avatarColin Ian King <colin.king@canonical.com>
Reviewed-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      1f0fa85c
    • Andreas Kemnade's avatar
      mfd: rn5t618: Fix caching of battery related registers · 594f1935
      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: default avatarAndreas Kemnade <andreas@kemnade.info>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      594f1935
    • Andreas Kemnade's avatar
      mfd: rn5t618: Make restart handler atomic safe · cf84dc0b
      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: default avatarAndreas Kemnade <andreas@kemnade.info>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      cf84dc0b
    • Stephen Rothwell's avatar
      mfd: kempld-core: Fix 'assignment of read-only location' error · 564de762
      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: default avatarStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      564de762
    • Frank Lee's avatar
      mfd: axp20x: Allow the AXP803 to be probed by I2C · 85c30785
      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: default avatarFrank Lee <frank@allwinnertech.com>
Acked-by: default avatarChen-Yu Tsai <wens@csie.org>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      85c30785
    • Adam Thomson's avatar
      mfd: da9063: Add support for latest DA silicon revision · 9ece3601
      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: default avatarAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      9ece3601
    • Adam Thomson's avatar
      mfd: da9063: Fix revision handling to correctly select reg tables · 091c6110
      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: default avatarAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      091c6110
    • Tony Lindgren's avatar
      mfd: motorola-cpcap: Disable interrupt for suspend · 819e42e0
      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: default avatarTony Lindgren <tony@atomide.com>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      819e42e0
    • Michael Walle's avatar
      mfd: smsc-ece1099: Remove driver · 7d2594cd
      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: default avatarMichael Walle <michael@walle.cc>
Cc: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      7d2594cd
    • Lee Jones's avatar
      mfd: core: Make a best effort attempt to match devices with the correct of_nodes · 466a62d7
      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: default avatarLee Jones <lee.jones@linaro.org>
      466a62d7
  7. Aug 12, 2020