> Please stop sending new versions of your patches as reply to previous versions, > and please provide change logs. I have no idea what is different between > versions 2 and 3 of this patch, and v2 as well as v3 almost got lost. > > Guenter Sorry about that. And the changlogs of the patch 1/2 is: - V1 -> V2: Just remove the check for 'EMC2305_REG_DEVICE' instead of moving the functionality of 'emc2305_identify' - V2 -> V3: Reword the commit as there is no emc2304 changlogs of the patch 2/2 is: - V1 -> V2: No substantive changes, was going to send later, but v3 has being sent before that (sorry about that again) - V1 -> V3: Add 'emc2305_set_cur_state_shim' to avoid updating 'last_thermal_state' when cooling state is set by 'hwmon' subsystem The v3 patch 2/2 can be found at: https://lore.kernel.org/all/20221206055331.170459-2-nanpuyue@xxxxxxxxx/ Should I resend them? One more question about 'EMC2305_FAN_MAX_STATE': https://lore.kernel.org/all/20221206053029.169506-1-nanpuyue@xxxxxxxxx/ > The value range of the chip's 'FAN DRIVE SETTING' register is 0-255. > But currently, the driver can only set up to 10 values at most (even via > the 'hwmon' subsystem) when the 'thermal' subsystem is reachable, and > there is no way to increase this limit via "emc2305_platform_data". > > Should the "pdata->max_state > EMC2305_FAN_MAX_STATE" check be removed? > Or 'EMC2305_FAN_MAX_STATE' should be defined as '0xff'? > > This should be the third patch? > > > > pdata = dev_get_platdata(&client->dev); > > if (pdata) { > > if (!pdata->max_state || pdata->max_state > EMC2305_FAN_MAX_STATE) > > return -EINVAL; > > data->max_state = pdata->max_state;
