Am Mon, 12 Apr 2021 09:06:10 -0700 schrieb Guenter Roeck <linux@xxxxxxxxxxxx>: > 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@xxxxxxxxx>: > > > >> 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 > >> > > >
