Re: [PATCH 1/3] hwmon: (sht3x)remove sht3x_platform_data

[Guenter Roeck]

On 6/14/23 16:54, JuenKit Yip wrote:
> 在 2023/6/15 3:15, Guenter Roeck 写道:
> > On 6/14/23 08:02, JuenKit Yip wrote:
> > > 在 2023/6/14 20:57, Guenter Roeck 写道:
> > > > On 6/13/23 23:24, JuenKit Yip wrote:
> > > > > Since no in-tree driver supports it, the sht3x_platform_data was
> > > > > removed.
> > > > >
> > > > > - "blocking_io" property and its related code have been removed, and
> > > > > Single-Shot mode should be blocking in default.
> > > > >
> > > > > - "high-precision" property has been replaced to "repeatability" for
> > > > > matching datasheet.
> > > >
> > > > That needs to be three patches.
> > >
> > > Patch 1: remove sht3x_platform_data and its header file
> > >
> > > Patch 2: move "blocking_io" to struct sht3x_data
> > Essentially merge it with update_interval==0 since (if I understand
> > correctly) blocking mode and update_interval==0 will be equivalent.
> > With that in mind, a separate "blocking_io" variable should no
> > longer be needed.
> I reviewed the datasheet again, update_interval == 0 means Single-Shot
>
> mode which owns blocking(clock strench) and non-blocking(non-clock strench)
>
> options. If master supports clock-strench( I don't know how to detect it),
>
> the property may be reserved.

I see.

In practice, blocking mode was never really used, at least not in the
upstream kernel, since platform data was not set from any in-kernel
code. Given that it is pretty much untested, I would suggest to always
use non-blocking mode. This is only relevant if the chip is in
single-shot mode, so worst case the user would have to wait a bit longer
for results in that mode. I find that acceptable over the risk involved
when trying to use/support blocking mode.

Guenter