On Thu, Apr 28, 2016 at 03:22:15PM +0000, Stuart Henderson wrote: > On 2016-04-28, stan <st...@panix.com> 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. >
It does the work for the find and attach. After that, you'll need to plumb the AML to find the device location and IRQ/etc. But sdhc_acpi is a simple driver that has most of the system interface goo you need to get started. -ml
