Split personality device driver?

I've been given some hardware that uses a M41ST87W combined i2c RTC and tamper detect chip. The intention is to use the RTC part as the Linux RTC, and the tamper detect and RAM storage separately.

I've defined the RTC in the device tree with compatible = "m41t80", and it's detected and works fine as an RTC. However, when I try to use the device by opening the i2c device and set the slave address, I get an error that it's unavailable as it's locked by the RTC driver.

Is there an easy way round this?

Unfortunately the M41ST87W has only a single i2c slave address so the RTC and tamper/RAM registers are one contiguous block.

Alternatively, if there isn't an easy solution, would it be necessary to write a driver that registers both as an RTC driver and some other type of character driver for reading the other registers etc? Is it even possible to do that and, if so, can someone please point me at an example?

Many thanks

I would try enabling the i2c part first, or doing it together. This could be done with a 'preinstall' command in /etc/modprobe.d/.

It may be that with separate drivers, that won't both work, and firmware could be another question. Please check these.

Hi,

Many thanks for your reply. Would you be able to expand a little on your answer though please? I'm quite new to embedded Linux (and Linux in general to be honest), and the "enabling the i2c part first" comment makes me wonder if my question was a bit confusing.

The M41ST87W (https://www.st.com/en/clocks-and-timers/m41st87w.html) has a single i2c slave address (0x68 in 7-bit mode) that allows access to all of its registers and memory so all the RTC functionality is handled through that address, and so is the tamper functionality, and access to its internal RAM.

If I don't define the M41ST87W in the device tree, I can access all its information by fd = open("/dev/i2c-0", O_RDWR) in my code then ioctl(fd, I2C_SLAVE, 0x68) etc. However, if I do add the M41ST87W in the device tree, with 'compatible = "m41t80"', it's matched as an RTC only, not surprisingly, and the ioctl() call above fails because the driver has the device locked or something.

Would the technique you suggested help in this case? In the meantime I'll look up the preinstall you mentioned.

My thoughts on it needing to be a single module (or something) we're due to the single i2c slave address having to be accessed for the RTC function as well as all the other functions, so control of access may be needed (?).

Originally Posted by cosimo193 Split personality device driver?

That's a poor choice of words IMO.
Composite-function or compound-device driver would be better.

Originally Posted by cosimo193 Is it even possible to do that and, if so, can someone please point me at an example?

Since you have the hardware, you need to inspect and play with that driver more.
A quick review indicates that drivers/rtc/rtc-m41t80.c is more than just a RTC driver.
If you select CONFIG_RTC_DRV_M41T80_WDT, then apparently you will also get a watchdog timer!
If you select CONFIG_COMMON_CLK, then apparently you will also get access to the built-in 32.768 kHz oscillator!

Note that each additional device/functionality (i.e. WDT and oscillator) has a set of routines listed in a xxx_ops structure, and that xxx_ops structure with other information in a device structure is registered with a device interface (i.e. misc_register() and clk_register()).
Unfortunately that driver does not already support other capabilities of that chip (such as the tamper function and RAM), but what you want to do may be possible.
The Miscellaneous Character Drivers looks promising.

Regards

Expanding on my answer, blue_z has grokked the driver code and obsoleted it!

If some bits don't stand up and work, there's a reason. Either they're not implemented, not configured in the kernel, or not set up correctly. This may be one of those cases where you have to become an expert just to make it work.

Originally Posted by blue_z That's a poor choice of words IMO. Composite-function or compound-device driver would be better.

Thanks.

Originally Posted by blue_z Since you have the hardware, you need to inspect and play with that driver more. A quick review indicates that drivers/rtc/rtc-m41t80.c is more than just a RTC driver. If you select CONFIG_RTC_DRV_M41T80_WDT, then apparently you will also get a watchdog timer! If you select CONFIG_COMMON_CLK, then apparently you will also get access to the built-in 32.768 kHz oscillator!

I've been through that code a number of times but, until now, I'd mistakenly assumed those bits were all connected with the RTC rather than being devices themselves.

Originally Posted by blue_z Note that each additional device/functionality (i.e. WDT and oscillator) has a set of routines listed in a xxx_ops structure, and that xxx_ops structure with other information in a device structure is registered with a device interface (i.e. misc_register() and clk_register()).

So I should expect to see 3 devices for that chip if I enable those config options?

Originally Posted by blue_z Unfortunately that driver does not already support other capabilities of that chip (such as the tamper function and RAM),

Yes, it would appear so.

Originally Posted by blue_z but what you want to do may be possible.

It looks like it may be.

Originally Posted by blue_z The Miscellaneous Character Drivers looks promising. Regards

Thanks for all that, it's been enlightening.

Originally Posted by cosimo193 I've been through that code a number of times but, until now, I'd mistakenly assumed those bits were all connected with the RTC rather than being devices themselves.

Recognizing the xxx_ops structures and xxx_register() calls would be overlooked by someone "quite new to embedded Linux (and Linux in general)".
But then there's the obvious comment:

#ifdef CONFIG_RTC_DRV_M41T80_WDT
/*
 *****************************************************************************
 *
 * Watchdog Driver
 *
 *****************************************************************************
 */
...

Originally Posted by cosimo193 So I should expect to see 3 devices for that chip if I enable those config options?

I've never used these interfaces, so I'm not guaranteeing anything.
What do you think I meant by suggesting that you need to "play with that driver more"?


Regarding the RAM on that chip:
Apparently the old interface for nonvolatile memory on RTC chips utilized the misc char device interface (i.e. minor number NVRAM_MINOR or 144).
That interface has been replaced with the nvmem interface as described in Documentation/nvmem/nvmem.txt.
You can look for examples that use struct nvmem_config and call rtc_nvmem_register().

Regards