On 2016-04-28, stan <[email protected]> wrote: > On Thu, Apr 28, 2016 at 02:18:25PM +0100, Stuart Henderson wrote: >> On 2016/04/28 08:56, stan wrote: >> > On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote: >> > > Stan, can you send the information that is output when you run >> > > sendbug -P as root? Just putting the whole thing inline in a >> > > reply-to-all to this mail would be fine. Please add "sysctl hw" >> > > output as well. Ideally we want a way to identify the watchdog >> > > itself rather than the general machine type etc. which is why >> > > I'm hoping they follow Microsoft's spec (which is the de-facto >> > > standard for this). >> > >> > >> > Sorry got distracted and frgot to cc the list. >> >> OK, pity, there doesn't seem to be anything to properly identify >> the watchdog in acpi tables. Just the vendor-specific thing which >> needs reading to figure things out further. If they had followed >> the usual spec then the driver would have been *very* generally >> useful. >> >> In that case maybe the approach would be to do something similar >> to acpithinkpad, but matching SECD instead of MHKV, and then >> looking for the SEL0002 HID. But I only know a bit about how >> to find my way round the decompiled files, so ignore me if >> a real ACPI hacker steps in with a better idea ;) >> >> > hw.vendor=Schweitzer Engineering Laboratories, Inc. >> > hw.product=SEL-3355 >> >> An alternative might be to match on vendor/product, see the last >> commit to sys/dev/ic/re.c for how to do this, but then you're >> having to look at fixed addresses which they seem to be providing >> via acpi. >> > > Let me apologize right here for my lack of knowledge as to low level > hardware coding. > > So, given that, please help me to understand why reading the DSDT ACPI > table and finding the SEL0002 is not the correct solution here? BTW, they > also identify an SEL0001 device, but I have not asked them what that is, > and )so far) I do not need to know. For what it is worth this hardware > vendor has been very helpful, and the corporate philosophy is to do things > "the right way". For instance, they released code to support this device for > Linux. When I talked to them, i brought up liscneing concerns with the > BSD's. The reply was, already been there, thought about that. It is dual > GPL, and BSD liscneced. Really a pleasant sunrise, as this is not in their > mainstream area of expertise. i was really pleased that the project team > had researched the OSS issues that well.
I was just chatting to mlarkin about this, he hasn't looked at the code but gave a few suggestions. I was wrong about the need to look for the SECD container - he gave an example of a better driver to crib from, sdhc_acpi, which is pretty simple in itself and shows the parts needed to find the device in the DSDT. Basically it just involves passing an array containing "SEL0002" to acpi_matchhids and it does the work.
