Re: Common device driver classes?

From: M. Warner Losh (imp_at_bsdimp.com)
Date: 12/12/03

  • Next message: Bruce M Simpson: "Re: Common device driver classes?" 
    Date: Thu, 11 Dec 2003 16:21:19 -0700 (MST)
To: nate@root.org

    In message: <20031211145311.Q51054@root.org>
                Nate Lawson <nate@root.org> writes:
    : This leaves my second question, which is how to make multiple hw-dependent
    : drivers that implement the same interface (sysctls) such that if one
    : probes ok, others of the same "type" don't attach. For instance, there
    : are multiple ways to control the Centrino -- both SpeedStep and ACPI
    : performance states. However, if the speedstep driver has attached, it
    : should supersede the ACPI driver since it offers more hw-aware control.

    acpi driver's probe returns -100, speedstep returns -10. attach
    routine does the dynamic sysctl creation, detach does the destroy.
    Only one of the attach routines will get called. This is exactly the
    same as the pci and the acpi pci goo.

    : So each CPU should have exactly one cpufreq driver attached and the one
    : that provides the best control. Warner suggested making a bus driver for
    : cpufreq that attaches to the "winner" of the probe and provides the
    : generic interface like this:

    cpu freq bus not needed, since all the frequency things would attach
    to a cpu.

    : Is that how miibus works? Is that an appropriate approach here?

    Yes and I don't think so. miibus has lots of upstream attachments,
    which isn't the case here.

    : One
    : issue is that other systems in the kernel will need a generic way to
    : control the cpu. For instance, passive cooling by acpi_thermal needs to
    : be able to use the cpufreq0 interface (through devclass_get_device) to
    : find what clock rates are available and adjust the clock rate without
    : caring about the underlying hardware. Advice on the above approach is
    : welcome.

    Sounds like a .m interface to me, but your milage may vary.

    Warner
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Bruce M Simpson: "Re: Common device driver classes?"

    Relevant Pages

    • Re: rdmsr from userspace
      ... privilege level and thus is not permitted from userland. ... I don't like interface of that device, ... CPU tweaking for bugs workaround without patching the kernel; ... I would prefer to have a microcode driver than a microcode ...
      (freebsd-hackers)
    • G33 graphics broken after 2.6.23-rc6
      ... driver from sf.net might fix) and graphics. ... Couldn't bind memory for front buffer ... CPU: Physical Processor ID: 0 ... registered new interface driver usbfs ...
      (Linux-Kernel)
    • Re: rdmsr from userspace
      ... I don't like interface of that device, I think that ioctl approach would be preferable in this case. ... While I think this is good for testing and development, I prefer having a device driver to handle that specific MSR than a generic /dev/cpuN where you can issue MSRs. ... CPU tweaking for bugs workaround without patching the kernel; ... Regarding to your two last points, I would prefer to have a microcode driver than a microcode userland utility that relies on devcpu. ...
      (freebsd-hackers)
    • DLKM load/unload question(s)
      ... I've been tasked with porting a device driver from Solaris to HPUX 11i. ... I've created pseudo class drivers under HPUX before but never an interface / ... seeing some odd behavior with respect to attach() when loading and unloading ...
      (comp.sys.hp.hpux)
    • Multi-threaded bonding driver.
      ... IRQs for the bonding driver is handled by only 1 CPU. ... It seems useless to have a bond interface driver if its not ...
      (comp.os.linux.development.system)