From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-watchdog@vger.kernel.org, kernel@pengutronix.de
Subject: Re: watchdog max63xx driver doesn't match datasheet?
Date: Fri, 15 Jan 2016 15:21:43 +0100 [thread overview]
Message-ID: <20160115142143.GL24441@pengutronix.de> (raw)
In-Reply-To: <5698D62C.1020106@arm.com>
Hello Marc,
On Fri, Jan 15, 2016 at 11:21:16AM +0000, Marc Zyngier wrote:
> On 15/01/16 10:49, Uwe Kleine-König wrote:
> > 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.
>
> 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.
> > 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... ;-)
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
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
prev parent reply other threads:[~2016-01-15 14:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 10:49 watchdog max63xx driver doesn't match datasheet? Uwe Kleine-König
2016-01-15 11:21 ` Marc Zyngier
2016-01-15 14:21 ` Uwe Kleine-König [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160115142143.GL24441@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=linux-watchdog@vger.kernel.org \
--cc=marc.zyngier@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).