Skip to content

Day22 Learning Log

Topic

Active Update Models - Polling Mode for I2C hwmon Driver

What I worked on

Today I extended the Day21 I2C hwmon sensor driver to support a background polling model.

The main goal was to separate:

  • sensor update path
  • hwmon read path

Instead of refreshing sensor data during every read, the driver now uses delayed work to periodically update a cached temperature value.

What I implemented

  • added delayed_work for periodic sensor refresh
  • added polling_enable
  • added polling_interval
  • kept existing cache fields
  • changed hwmon read logic:
  • polling enabled -> cache-only
  • polling disabled -> fallback to on-demand update
  • added/remove handling for polling worker lifecycle

What I learned

1. Polling is an asynchronous update model

In on-demand mode, userspace read drives sensor activity.

In polling mode, the driver updates data in the background and userspace only reads cached results.

This makes the read path cleaner and more predictable.

2. delayed_work is not real-time

Polling with delayed work is suitable for periodic best-effort updates, but there can still be scheduling jitter.

3. Cache validity matters

When the first valid sample is not ready, the driver should not return fake data.

Returning -EAGAIN is a reasonable design for cache-not-ready condition.

4. Direct access and cache-based paths can coexist

temp1_input and temp_raw serve different purposes:

  • temp1_input for normal hwmon usage
  • temp_raw for debugging and direct validation

Problem encountered

At first, reading temp1_input returned:

Resource temporarily unavailable

Reason:

  • the cache was not valid yet
  • the driver returned -EAGAIN

This was expected once the read path became cache-only in polling mode.

Test result

I verified:

  • polling worked correctly
  • interval control worked
  • disable/enable control worked
  • cached hwmon reading behaved as expected

I also fixed a shell script issue where brace expansion did not work as expected in the test loop.

Key takeaway

Day22 helped me understand how Linux drivers can move from:

  • synchronous read-triggered updates

to:

  • asynchronous background updates with cached reads

This is a useful pattern for real sensor drivers and prepares well for an interrupt-driven model.

Next step

Day23 will be a good place to explore:

  • interrupt-driven update model
  • GPIO IRQ as data-ready signal
  • top half / bottom half design for sensor refresh