watchdog max63xx driver doesn't match datasheet?
Hello Marc,
when comparing the driver drivers/watchdog/max63xx_wdt.c (in Linux 4.4) with the datasheet
https://datasheets.maximintegrated.com/en/ds/MAX6369-MAX6374.pdf I wonder if I have a different documentation that you had back in 2009 when you wrote the driver. According to "my" datasheet these chips have 3 logic inputs SET1, SET2 and SET3 and depending on these the timeout is configured. In your driver however you do:
wdt->base = devm_ioremap_resource(&p->dev, mem);
and to select the timeout you write a byte to this address.
The driver seems to be used in arch/arm/mach-ixp4xx/vulcan-setup.c and arch/arm/mach-pxa/zeus.c and I guess there the device sits behind some hardware that sets an output for each bit set in the respective register.
Did I get this right? If so, a patch to extend the driver to have a binding like:
{
compatible = "maxim,max6371";
set-gpios = <&gpio1 12 0>, ...;
wdi-gpios = <&gpio3 ...>, ...;
}would be fine, right?
Best regards
Uwe
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
Hi Uwe,
Quoted 10 lines · Uwe Kleine-König
Hello Marc,
when comparing the driver
drivers/watchdog/max63xx_wdt.c(in Linux 4.4) with the datasheet
https://datasheets.maximintegrated.com/en/ds/MAX6369-MAX6374.pdf I wonder if I have a different documentation that you had back in 2009 when you wrote the driver. According to "my" datasheet these chips have 3 logic inputs SET1, SET2 and SET3 and depending on these the timeout is configured. In your driver however you do:
Quoted 8 lines
wdt->base = devm_ioremap_resource(&p->dev, mem);and to select the timeout you write a byte to this address.
The driver seems to be used in
arch/arm/mach-ixp4xx/vulcan-setup.candarch/arm/mach-pxa/zeus.cand I guess there the device sits behind some hardware that sets an output for each bit set in the respective register.
Exactly. The driver states in the top comment section:
* This driver assumes the watchdog pins are memory mapped (as it is
* the case for the Arcom Zeus). Should it be connected over GPIOs or
* another interface, some abstraction will have to be introduced.
Quoted 10 lines
Did I get this right? If so, a patch to extend the driver to have a binding like:
{ compatible = "maxim,max6371"; set-gpios = <&gpio1 12 0>, ...; wdi-gpios = <&gpio3 ...>, ...; }would be fine, right?
Perfectly fine by me. And if you want to make sure you didn't break the existing setups, you are welcome to get my boards... ;-)
Cheers,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...
Hello Marc,
Quoted 20 lines · Marc Zyngier
Quoted 10 lines · Uwe Kleine-König
Hello Marc,
when comparing the driver
drivers/watchdog/max63xx_wdt.c(in Linux 4.4) with the datasheet
https://datasheets.maximintegrated.com/en/ds/MAX6369-MAX6374.pdf I wonder if I have a different documentation that you had back in 2009 when you wrote the driver. According to "my" datasheet these chips have 3 logic inputs SET1, SET2 and SET3 and depending on these the timeout is configured. In your driver however you do:Quoted 8 lines
wdt->base = devm_ioremap_resource(&p->dev, mem);and to select the timeout you write a byte to this address.
The driver seems to be used in
arch/arm/mach-ixp4xx/vulcan-setup.candarch/arm/mach-pxa/zeus.cand I guess there the device sits behind some hardware that sets an output for each bit set in the respective register.
Quoted 5 lines
Exactly. The driver states in the top comment section:
* This driver assumes the watchdog pins are memory mapped (as it is
* the case for the Arcom Zeus). Should it be connected over GPIOs or
* another interface, some abstraction will have to be introduced.
Ah, it seems I didn't look deep enough into this driver. So we agree here.
Quoted 9 lines
Quoted 9 lines
Did I get this right? If so, a patch to extend the driver to have a binding like:
{ compatible = "maxim,max6371"; set-gpios = <&gpio1 12 0>, ...; wdi-gpios = <&gpio3 ...>, ...; }
Quoted 4 lines
Quoted 1 line
would be fine, right?
Perfectly fine by me. And if you want to make sure you didn't break the existing setups, you are welcome to get my boards... ;-)
Looking through the board files, I think I'm not interested in pre-dt ARMv5, thanks. I think we can save the postage, thanks. When (and if) I address the problem I think I can manage keeping them functional even without the hardware. (But if you want to dust off your old boards you're welcome to test the patches of course.)
If however you have a spare board with a fast processor, S-ATA, DVB-C, much RAM and a big touch screen, then I would invest the postage :-)
Best regards
Uwe
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |