From: Henning Schild <henning.schild@siemens.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
platform-driver-x86@vger.kernel.org,
linux-watchdog@vger.kernel.org,
Srikanth Krishnakar <skrishnakar@gmail.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Gerd Haeussler <gerd.haeussler.ext@siemens.com>,
Wim Van Sebroeck <wim@linux-watchdog.org>,
Mark Gross <mgross@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>, Pavel Machek <pavel@ucw.cz>
Subject: Re: [PATCH v3 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs
Date: Mon, 12 Apr 2021 18:17:36 +0200 [thread overview]
Message-ID: <20210412181736.6b18f667@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <610b566d-10a8-fa6b-145d-db7a453f97cf@roeck-us.net>
Am Mon, 12 Apr 2021 09:06:10 -0700
schrieb Guenter Roeck <linux@roeck-us.net>:
> On 4/12/21 8:35 AM, Henning Schild wrote:
> > Am Thu, 1 Apr 2021 18:15:41 +0200
> > schrieb "Enrico Weigelt, metux IT consult" <lkml@metux.net>:
> >
> >> On 29.03.21 19:49, Henning Schild wrote:
> >>
> >> Hi,
> >>
> >>> This driver adds initial support for several devices from Siemens.
> >>> It is based on a platform driver introduced in an earlier commit.
> >>>
> >>
> >> Where does the wdt actually come from ?
> >>
> >> Is it in the SoC ? (which SoC exactly). SoC-builtin wdt is a
> >> pretty usual case.
> >>
> >> Or some external chip ?
> >>
> >> The code smells a bit like two entirely different wdt's that just
> >> have some similarities. If that's the case, I'd rather split it
> >> into two separate drivers and let the parent driver (board file)
> >> instantiate the correct one.
> >
> > In fact they are the same watchdog device. The only difference is
> > the "secondary enable" which controls whether the watchdog causes a
> > reboot or just raises an alarm. The alarm feature is not even
> > implemented in the given driver, we just enable that secondary
> > enable regardless.
>
> Confusing statement; I can't parse "we just enable that secondary
> enable regardless". What secondary enable do you enable ?
>
> The code says "set safe_en_n so we are not just WDIOF_ALARMONLY",
> which suggests that it disables the alarm feature, and does make
> sense.
Yes go with the second statement. But the alarm is the default after
boot, and turning it off needs to be done with p2sb gpio on the 427.
> > In one range of devices (227E) that second enable is part of a
> > pio-based control register. On the other range (427E) it
> > unfortunately is a P2SB gpio, which gets us right into the
> > discussion we have around the LEDs.
> > With that i have my doubts that two drivers would be the way to go,
> > most likely not.
> >
>
> Reading the code again, I agree. Still, you'll need to sort out how
> to determine if the watchdog or the LED driver should be enabled,
> and how to access the gpio port. The GPIO pin detection and use
> for 427E is a bit awkward.
Yes it is awkward, and that is exactly the discussion happening for the
LEDs. Using generic GPIO code, the mail was more to Andy as i am hoping
he might help me connect the dots here. On the other hand i wanted wdt
discussions in the wdt thread, and not talk about that one gpio-pin in
the LED thread.
regards,
Henning
> Thanks,
> Guenter
>
> > Only that i have no clue which pinctrl driver should be used here.
> > My guess is "sunrisepoint" because the CPUs are "SkyLake" i.e.
> > i5-6442EQ, i3-6102E
> > And "grep INT344B /sys/firmware/acpi/tables/DSDT" matches. I booted
> > a kernel patched with the series from Andy but the
> > "pinctrl-sunrisepoint" does not seem to even claim the memory.
> > Still trying to understand how to make use of these pinctrl drivers
> > they are in place but i lack example users (drivers). If they
> > should be available in sysfs, i might be looking at the wrong place
> > ... /sys/class/gpio/ does not list anything
> >
> > regards,
> > Henning
> >
> >
> >
> >>
> >> --mtx
> >>
> >
>
next prev parent reply other threads:[~2021-04-12 16:27 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-29 17:49 [PATCH v3 0/4] add device drivers for Siemens Industrial PCs Henning Schild
2021-03-29 17:49 ` [PATCH v3 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices Henning Schild
2021-11-26 12:39 ` Henning Schild
2021-03-29 17:49 ` [PATCH v3 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs Henning Schild
2021-03-30 11:04 ` Andy Shevchenko
2021-03-30 11:58 ` Henning Schild
2021-03-30 12:15 ` Andy Shevchenko
2021-03-30 12:30 ` Henning Schild
2021-03-30 12:41 ` Andy Shevchenko
2021-03-30 15:23 ` Henning Schild
2021-03-31 15:40 ` Andy Shevchenko
2021-04-01 10:44 ` Henning Schild
2021-04-01 11:04 ` Andy Shevchenko
2021-04-12 11:56 ` Henning Schild
2021-05-05 14:58 ` Enrico Weigelt, metux IT consult
2021-04-12 15:15 ` Henning Schild
2021-11-26 13:28 ` Henning Schild
2021-11-26 14:02 ` Andy Shevchenko
2021-11-26 14:44 ` Henning Schild
2021-11-26 14:59 ` Andy Shevchenko
2021-11-26 19:54 ` Henning Schild
2021-11-25 17:11 ` Henning Schild
2021-03-29 17:49 ` [PATCH v3 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs Henning Schild
2021-04-01 16:15 ` Enrico Weigelt, metux IT consult
2021-04-06 14:52 ` Henning Schild
2021-04-07 8:53 ` Andy Shevchenko
2021-04-07 12:17 ` Guenter Roeck
2021-11-26 13:18 ` Henning Schild
2021-04-12 15:35 ` Henning Schild
2021-04-12 16:06 ` Guenter Roeck
2021-04-12 16:17 ` Henning Schild [this message]
2021-11-25 17:08 ` Henning Schild
2021-11-25 17:10 ` Henning Schild
2021-03-29 17:49 ` [PATCH v3 4/4] platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs Henning Schild
2021-03-29 18:00 ` [PATCH v3 0/4] add device drivers for Siemens Industrial PCs Henning Schild
2021-04-07 11:36 ` Hans de Goede
2021-04-12 11:27 ` Henning Schild
2021-07-12 11:35 ` Henning Schild
2021-07-12 12:09 ` Andy Shevchenko
2021-07-12 16:11 ` Henning Schild
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=20210412181736.6b18f667@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=andy.shevchenko@gmail.com \
--cc=gerd.haeussler.ext@siemens.com \
--cc=hdegoede@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lkml@metux.net \
--cc=mgross@linux.intel.com \
--cc=pavel@ucw.cz \
--cc=platform-driver-x86@vger.kernel.org \
--cc=skrishnakar@gmail.com \
--cc=wim@linux-watchdog.org \
/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).