Re: FW: watchdog suport for new hardware
Theo / Stuart,
I am e-mailing regarding the source code that Stan Brown sent for a new
watchdog driver. We modeled our code off of the wbsio driver that does a
write to the Super I/O chip first in order to read the device ID and
compare it with a known list of device IDs. The device that we wrote the
driver for does have an entry in the DSDT table of SEL0002, but when we
wrote the driver as an acpi device, the probe function never found an HID
of SEL0002.
I understand your concern about âsteppingâ on another device. This device
is found at IO port 0x192 which could potentially be re-used by some other
device I would assume. Is there a way to read the DSDT tables from within
an ISA probe function? I couldnât wrap my head around that process as the
ISA bus on this particular machine is hosted by a PCI-ISA bridge. Any help
you could provide would be appreciated.
Thanks,
Chase Davis
>
> From: stan
> To: Stuart Henderson
> Subject: Re: FW: Re: watchdog suport for new hardware
> Date: Tue, 26 Apr 2016 11:57:48 -0400
> User-Agent: Mutt/1.5.4i
> X-Operating-System: Debian GNU/Linux
> X-Kernel-Version: 2.4.23
> X-Uptime: 11:51:45 up 91 days, 10:53, 1 user, load average: 0.00, 0.00,
> 0.00
> X-Editor: gVim
>
> On Tue, Apr 26, 2016 at 03:44:46PM +, Stuart Henderson wrote:
>
> On 2016-04-26, Theo de Raadt wrote:
>
> int
>
> selwd_probe(struct device *parent, void *match, void *aux)
>
> {
>
>struct isa_attach_args *ia = aux;
>
>bus_space_tag_t iot;
>
>bus_space_handle_t ioh;
>
>
>
>/* Match by device ID */
>
>iot = ia->ia_iot;
>
>if (bus_space_map(iot, ia->ipa_io[0].base, SELWD_IOSIZE, 0, &ioh))
>
>return 0;
>
>
>
> ...
>
>
>
>/* read model number */
>
>char *model = malloc(sizeof(char)*16, M_DEVBUF, M_WAITOK | M_ZERO);
>
>selwd_read_modelno(iot, ioh, model);
>
>
>
> This is worrying. It assumes that all systems have this hardware.
>
>
>
> And it starts by doing a "write".
>
>
>
> Is there no WDRT or WDAT table in ACPI on this hardware? Most "modern"
>
> (2006-on) watchdogs on PCs with ACPI support have the WDRT table described
>
> in https://msdn.microsoft.com/en-us/windows/hardware/gg463320.aspx
>
>
>
> Check for /tmp/acpi.WD[AR]T.* files after running acpidump -o /tmp/acpi ..
>
>
>
>
> Acording to the vendor documentation, yes we should be able to find SEL0002
> in the DSDT table. I am afrid I do not understand how to chek this. Could
> you point me to some documentation as to how to do this?
>
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> - End forwarded message -
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>
> --
>
> Confidentiality Notice:
>
> The information contained in this message is private and confidential.
> This information is intended only for the individual or entity named above.
> If the reader of this message is not the intended recipient, you are hereby
> notified that any use, review, dissemination, distribution, copying or
> action taken based on this message or its attachments, if any, is strictly
> prohibited. If you are not the intended recipient, please contact the
> sender by reply email and delete or destroy all copies of this message and
> any attachments. Thank you.
>
--
Chase Davis
Re: FW: Re: watchdog suport for new hardware
Mike,
We took your suggestion and re-wrote the driver to model sdhc_acpi. I
have attached the new code. However, the match function never returns
a 1. We put temporary print statements in the match routine. It is
being called several times during the kernel boot process, but it
never finds a device with HID SEL0002. Do you have any suggestions for
why it would show up in the DSDT tables when we do an acpidump, but
that the match routine never finds it?
This is a snippet from the dmesg boot log
Attempting to match SEL: result (0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
Attempting to match SEL: result (0)
Attempting to match SEL: result (0)
Attempting to match SEL: result (0)
Attempting to match SEL: result (0)
acpihpet0 at acpi0: 14318179 Hz
Attempting to match SEL: result (0)
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
int
sel_acpi_match(struct device *parent, void *match, void *aux)
{
struct acpi_attach_args *aaa = aux;
struct cfdata *cf = match;
printf("Attempting to match SEL: ");
int res = acpi_matchhids(aaa, sel_hids, cf->cf_driver->cd_name);
printf("result (%d)\n", res);
return res;
}
Thanks,
Chase
[demime 1.01d removed an attachment of type text/x-csrc which had a name of
sel_acpi.c]
[demime 1.01d removed an attachment of type text/x-chdr which had a name of
selreg.h]
Re: FW: Re: watchdog suport for new hardware
This was added to GENERIC:
sel* at acpi?
and these four lines were added to files.acpi:
# SEL embedded controller
device sel
attach sel at acpi with sel_acpi
file dev/acpi/sel_acpi.c sel_acpi
With SEL0002 being the first item in the array, shouldn't it at least
match it if it exists? We will add NULL to the HID array and see what
happens.
On Tue, May 3, 2016 at 5:29 PM, Mike Larkin wrote:
> On Tue, May 03, 2016 at 03:32:34PM -0500, Chase Davis wrote:
>> Mike,
>>
>> We took your suggestion and re-wrote the driver to model sdhc_acpi. I
>> have attached the new code. However, the match function never returns
>> a 1. We put temporary print statements in the match routine. It is
>> being called several times during the kernel boot process, but it
>> never finds a device with HID SEL0002. Do you have any suggestions for
>> why it would show up in the DSDT tables when we do an acpidump, but
>> that the match routine never finds it?
>>
>> This is a snippet from the dmesg boot log
>>
>> Attempting to match SEL: result (0)
>> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>> Attempting to match SEL: result (0)
>> Attempting to match SEL: result (0)
>> Attempting to match SEL: result (0)
>> Attempting to match SEL: result (0)
>> acpihpet0 at acpi0: 14318179 Hz
>> Attempting to match SEL: result (0)
>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>>
>> int
>> sel_acpi_match(struct device *parent, void *match, void *aux)
>> {
>> struct acpi_attach_args *aaa = aux;
>> struct cfdata *cf = match;
>> printf("Attempting to match SEL: ");
>> int res = acpi_matchhids(aaa, sel_hids, cf->cf_driver->cd_name);
>> printf("result (%d)\n", res);
>> return res;
>> }
>>
>> Thanks,
>> Chase
>
> I think this diff is missing some parts. Like GENERIC?
>
> Also, you need a NULL after your last HID or matchhids will walk all
> through memory until it hits a NULL.
>
> -ml
>
>> /*$OpenBSD: sel.c,v 1.0 2016/04/01 05:00:00 jsg Exp $ */
>> /*
>> * Copyright (c) 2016 PREMIER System Integrators
>> *
>> * Permission to use, copy, modify, and distribute this software for any
>> * purpose with or without fee is hereby granted, provided that the above
>> * copyright notice and this permission notice appear in all copies.
>> *
>> * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
>> * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
>> * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
>> * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>> * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
>> * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>> * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>> *
>> * Schweitzer Engineering Laboratories: SEL-3355 Embedded controller
>> */
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> #include
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> #include
>>
>> struct sel_host;
>>
>> struct sel_softc {
>> /* sc_dev must be the first item in the struct */
>> struct device sc_dev;
>> struct sel_host **sc_host;
>> };
>>
>> struct sel_acpi_softc {
>> struct sel_softcsc;
>> struct acpi_softc *sc_acpi;
>> struct aml_node *sc_node;
>>
>> /* device access through bus space */
>> bus_space_tag_t sc_iot;
>> bus_space_handle_t sc_ioh;
>> bus_addr_t sc_addr;
>> bus_size_t sc_size;
>>
>> struct sel_host *sc_host;
>> };
>>
>> int sel_wait(bus_space_tag_t, bus_space_handle_t, bool);
>>
>> /* Autoconfiguration glue */
>> int sel_acpi_match(struct device *, void *, void *);
>> void sel_acpi_attach(struct device *, struct device *, void *);
>> int sel_print(void *, const char *);
>> int sel_wd_cb(void *, int);
>>
>> /* functions to interact with the controller */
>> void sel_write_wdog(bus_space_tag_t, bus_space_handle_t, int);
>> u_int8_t sel_read_wdog(bus_space_tag_t, bus_space_handle_t);
>> u_int8_t sel_read_status(bus_space_tag_t, bus_space_handle_t);
>> void sel_abort(bus_space_tag_t, bus_space_handle_t);
>> u_int32_t sel_read_boardi
