Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Jan 2012 15:13:17 +0200
From:      Aleksandr Rybalko <ray@ddteam.net>
To:        Oleksandr Tymoshenko <gonzo@freebsd.org>
Cc:        Ben Gray <ben.r.gray@gmail.com>, freebsd-arch@freebsd.org
Subject:   Re: Extending sys/dev/mii
Message-ID:  <20120121151317.d0532390.ray@ddteam.net>
In-Reply-To: <4F1A3B58.7040001@freebsd.org>
References:  <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <F60B2B70-049F-4497-BBA8-3C421088C1EA@lassitu.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> <4F1A3B58.7040001@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Jan 2012 20:13:12 -0800
Oleksandr Tymoshenko <gonzo@freebsd.org> 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.
> _______________________________________________
> 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"

I use the same:
devclass_get_device(devclass_find(driver_name), 0);
in my floatphy0. But i save device_t of device driver i found. And make
it on first call to my device. Since it is pseudo PHY driver, i try to
find master device driver on first PHY status or poll request. And
driver is happy with that.

Only one problem here, if master will be detached (because unload or
some problem) then address for master device_t became wrong.

I think it easy to solve it with use of event handler for device
attache/detach. Then we be able to find master device on _attach stage
or when event handler will be invoked. And clear saved master device_t
when device detach event handler will be invoked.
We need only add EVENTHANDLER_INVOKE to devadded/devremoved in the
sys/kern/subr_bus.c.

WBW
-- 
Aleksandr Rybalko <ray@ddteam.net>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120121151317.d0532390.ray>