lockdep splat involving iio-hwmon and iio-rescale drivers

[Rasmus Villemoes <ravi@prevas.dk>]

Hi

I have an am335x board where the AINx channels are used for various
voltage/current measurement, i.e. they have a variety of current shunts
and voltage dividers in front of them. Describing those is pretty
straight-forward, and the resulting iio devices seem to work.

Now, I'd like to expose those as hwmon sensors, because there are other
i2c-attached ADCs on the board exposed that way, and it would be nice to
have them all available through "sensors" command in userspace. So
altogether, my .dts additions are

	ain {
		compatible = "iio-hwmon";
		io-channels = <&ain_12V 0>, <&ain_12V_i>, <&ain_3V3_i>, <&ain_Vin_i>, <&am335x_adc 4>;
	};

	ain_12V: ain-12V {
		compatible = "voltage-divider";
		io-channels = <&am335x_adc 0>;
		#io-channel-cells = <1>;
		output-ohms = <10000>;
		full-ohms = <110000>;
	};

	ain_12V_i: ain-12V-i {
		compatible = "current-sense-amplifier";
		io-channels = <&am335x_adc 1>;
		#io-channel-cells = <0>;
		sense-resistor-micro-ohms = <10000>;
		sense-gain-mult = <50>;
	};

	ain_3V3_i: ain-3V3-i {
		compatible = "current-sense-amplifier";
		io-channels = <&am335x_adc 2>;
		#io-channel-cells = <0>;
		sense-resistor-micro-ohms = <10000>;
		sense-gain-mult = <50>;
	};

	ain_Vin_i: ain-Vin-i {
		compatible = "current-sense-amplifier";
		io-channels = <&am335x_adc 3>;
		#io-channel-cells = <0>;
		sense-resistor-micro-ohms = <22000>;
		sense-gain-mult = <46400>;
		sense-gain-div = <1000>;
	};

[the fifth adm335x_adc channel is just to be used as-is, there's no
circuitry in front of that].

With this, running the 'sensors' command does produce sensible output,
but it also results in this splat:

  ============================================
  WARNING: possible recursive locking detected
  6.17.11 #5 Not tainted
  --------------------------------------------
  sensors/414 is trying to acquire lock:
  c1dc7b68 (&iio_dev_opaque->info_exist_lock){+.+.}-{3:3}, at: iio_read_channel_raw+0x20/0x6c
  
  but task is already holding lock:
  c1dd2b68 (&iio_dev_opaque->info_exist_lock){+.+.}-{3:3}, at: iio_read_channel_processed_scale+0x24/0xd8
  
  other info that might help us debug this:
   Possible unsafe locking scenario:
  
         CPU0
         ----
    lock(&iio_dev_opaque->info_exist_lock);
    lock(&iio_dev_opaque->info_exist_lock);
  
   *** DEADLOCK ***
  
   May be due to missing lock nesting notation
  
  4 locks held by sensors/414:
   #0: c31fd6dc (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0x44/0x4e4
   #1: c4f5a1c4 (&of->mutex){+.+.}-{3:3}, at: kernfs_seq_start+0x1c/0xac
   #2: c2827548 (kn->active#34){.+.+}-{0:0}, at: kernfs_seq_start+0x30/0xac
   #3: c1dd2b68 (&iio_dev_opaque->info_exist_lock){+.+.}-{3:3}, at: iio_read_channel_processed_scale+0x24/0xd8
  
  stack backtrace:
  CPU: 0 UID: 0 PID: 414 Comm: sensors Not tainted 6.17.11 #5 NONE 
  Hardware name: Generic AM33XX (Flattened Device Tree)
  Call trace: 
   unwind_backtrace from show_stack+0x10/0x14
   show_stack from dump_stack_lvl+0x44/0x60
   dump_stack_lvl from print_deadlock_bug+0x2b8/0x334
   print_deadlock_bug from __lock_acquire+0x13a4/0x2ab0
   __lock_acquire from lock_acquire+0xd0/0x2c0
   lock_acquire from __mutex_lock+0xa0/0xe8c
   __mutex_lock from mutex_lock_nested+0x1c/0x24
   mutex_lock_nested from iio_read_channel_raw+0x20/0x6c
   iio_read_channel_raw from rescale_read_raw+0x128/0x1c4
   rescale_read_raw from iio_channel_read+0xe4/0xf4
   iio_channel_read from iio_read_channel_processed_scale+0x6c/0xd8
   iio_read_channel_processed_scale from iio_hwmon_read_val+0x68/0xbc
   iio_hwmon_read_val from dev_attr_show+0x18/0x48
   dev_attr_show from sysfs_kf_seq_show+0x80/0x110
   sysfs_kf_seq_show from seq_read_iter+0xdc/0x4e4
   seq_read_iter from vfs_read+0x238/0x2e4
   vfs_read from ksys_read+0x6c/0xec
   ksys_read from ret_fast_syscall+0x0/0x1c
  Exception stack(0xe00b9fa8 to 0xe00b9ff0)
  9fa0:                   00000000 00000000 00000003 004639f0 00001000 00000000
  9fc0: 00000000 00000000 b6e80a7c 00000003 00000000 ffffffff 0046b1b8 bea555bc
  9fe0: 00001000 bea54f40 00000001 b6d89e6c

Just accessing a single property under /sys/class/hwmon/hwmonX/ also
results in a similar splat.

Am I doing things wrong, or is there a genuine problem hiding somewhere?

Rasmus