> 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".
> void
> selwd_read_modelno(bus_space_tag_t iot, bus_space_handle_t ioh, char* model)
> {
> /* read the MODEL NUMBER value from the controller */
> /* make sure status is 0 before proceeding */
> selwd_abort(iot, ioh);
> u_int8_t reg;
> int i = 0;
>
> /* write the READCFG command to the command register */
> selwd_conf_enable(iot, ioh, SELWD_CMD_READCFG);
> /* read the MODELNO data value from the data register */
> reg = selwd_conf_read(iot, ioh, SELWD_CFG_MODELNO);
> while (reg != 0 && i < 15) {
> model[i] = reg;
> /* make sure status is 0 before proceeding */
> selwd_abort(iot, ioh);
> /* write the READCFG command to the command register */
> selwd_conf_enable(iot, ioh, SELWD_CMD_READCFG);
> /* read the MODELNO data value from the data register */
> reg = selwd_conf_read(iot, ioh, SELWD_CFG_MODELNO);
> i++;
> }
>
> }
I do not know what IO port this lands at, but we have had bad experiences
with this strategy in the past. Specifically the uguru(4) chip which landed
right on top of an undocumented Dell server's cpu clock-generator, that was
even worse, since the clock generator appeared to change behaviour based only
upon read's...
