Extending sys/dev/mii

[Aleksandr Rybalko]

On Mon, 23 Jan 2012 23:45:29 -0800
Oleksandr Tymoshenko <gonzo at bluezbox.com> wrote:

>> 
>> On 2012-01-20, at 8:13 PM, Oleksandr Tymoshenko wrote:
>> 
>> > On 20/01/2012 5:43 PM, Warner Losh wrote:
>> >> 
>> >> On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote:
>> >>> The second problem is that there's currently no way to express a
>> >>> dependency between two devices other than a parent-child
>> >>> relationship.   I would be interested to learn why this appears
>> >>> to be so uncommon that I could not find any discussion of such a
>> >>> feature.  Has it really never before come up?
>> >> 
>> >> Sure there is: you can do it by name.  I wrote a driver that
>> >> attached to the ISA bus, but also needed to talk to the ppbus
>> >> that was attached to the printer.  My solution was to have a
>> >> post-attach name-lookup so that it could then call methods on the
>> >> other driver's device_t.  I wonder why we can't do that here?
>> > 
>> >    I've been thinking about it recently in regard to GPIO
>> > subsystem. And the same issue appeared during OMAP code import:
>> > there are at least two subsystems that are used by the rest of the
>> > drivers. Ben's suggested following solution: define kobj interface
>> > if_SUBSYTEM.m and then provide API call in form:
>> > 
>> >    int omap_prcm_clk_enable(clk_ident_t clk)
>> >    {
>> >        device_t prcm_dev;
>> > 
>> >        prcm_dev = devclass_get_device(devclass_find("omap_prcm"),
>> > 0); if (prcm_dev == NULL) {
>> >            printf("Error: failed to get the PRCM device\n");
>> >            return (EINVAL);
>> >        }
>> > 
>> >        return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk);
>> >    }
>> > 
>> > So it might make sense to create some kind of upper-level API for
>> > defining this kind of subsystems' APIs since every implementation
>> > would duplicate a lot of code: look for instance of specific
>> > devclass, check if it exists. Not sure how to do it at the moment
>> > though.
>> 
>> 
>> I tinkered a little bit with this idea and here is what I've come up
>> with so far:
>> 
>> http://people.freebsd.org/~gonzo/patches/horizontal-api.diff
>> 
>> this patch adds one more available declaration to .m files: APIMETHOD
>> In addition to usual kobj method declaration one more function is
>> generated. This function gets first device in devclass with the same
>> name as declared interface and uses it as object for respective
>> method call. 
>> 
>> Also if there is at least one APIMETHOD in interface one more
>> function called XXXX_available() is generated. It returns 1 if there
>> is device of required devclass.
>> 
>> Usage example:
>>        int maxpin;
>> 
>>        printf("GPIO available: %d\n", gpio_available());
>>        if (gpio_available()) {
>>            gpio_pin_max(&maxpin);
>>            printf("GPIO pins: %d\n", maxpin);
>>         }
>> 
>> Possible improvements: instead of using devclass for identifying
>> kobj, create way for device to explicitly register/deregister as an
>> API "provider". 

If I understand patch correct, it will search for device every "API"
call. Is it good?

>> 
>> 
>> Comments, ideas?_______________________________________________
>> freebsd-arch at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to
>> "freebsd-arch-unsubscribe at freebsd.org"


-- 
Alexandr Rybalko <ray at dlink.ua> 
aka Alex RAY <ray at ddteam.net>