--KlAEzMkarCnErv5Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 20, 2007 at 03:30:07PM +0200, Jachym Holecek wrote:
> # Marco Trillo 2007-10-20:
> > On 10/20/07, Jachym Holecek <freza@netbsd.org> wrote:
> > > This could be implemented by providing an autoconf(9) API to register
> > > new cfdata entries before device discovery is started. If the arch kn=
ows
> > > the list of devices and their addresses, it would simply convert firm=
ware
> > > device table into cfdata dictionaries and indirect-search iic(4) would
> > > then use it transparently.
> >=20
> > But this functionality is more controller-specific than
> > architecture-specific. In the macppc example, the OpenFirmware nodes
> > are ki2c(4) specific (and are in fact child nodes of the ki2c firmware
> > nodes) and should not affect for example cuda(4) or pmu(4) -- and it
> > should be possible to have all of these I2C controllers enabled
> > without conflicts.
>=20
> Ok, so ideally MD ki2c(4) should be able to tell autoconf(9) that i2cbus
> instance it's about to attach has a known set of child devices. We already
> have a MI way of describing "what device hangs off what with such-and-such
> locators": cfdata_t objects. Converting MD notation of device hierarchy

No, this is not what a cfdata_t represents.  It's a potential instance
of a driver, not a device.  In order to create a cfdata_t, you need the
name of a driver.

> into a cfdata_t should be trivial. So what's missing is a way for a device
> (ki2c0) to register additional set of cfdata_t objects (i2c devices) that
> are known to be children of some of its child (iicN) connected at given
> attribute (i2cbus).
>=20
> In other situations, you would inject new cfdata_t objects before
> autoconfiguration is started, or during autoconfiguration from MD
> device_register() hook.
>=20
> This doesn't sound hard to implement and has the advantage of being
> more general: this way, you could use MD device hierarchy knowledge
> for any indirect-config bus (think isa(4)).

Except the parent bus can't know about drivers able to claim a device
before it has called their match functions, and for that it needs a set
of cfdata_t.

Think of competing drivers for a device that identifies the same way to
the parent bus.

The issue at stake here is how to mix direct and indirect configurations
for a given bus.  It's possible under the current autoconf(9) framework
(albeit somewhat hackish).

The controler that attaches an iic instance has to pass a table of some
sort to the iic driver;  in the current autoconf(9) framework it would
unfortunately have to be through a pointer in the attach args (unless
you somehow delay attachment of children to give a chance to the parent
to set a property, but that's equally ugly).

Then the iic driver attaches its children in two distinct phases:
first, the direct configuration, enumerating the passed table.  The
trick here (again, in the current autoconf(9) framework) is to let
drivers know it's a direct configuration attempt.  That's a field to
add to the iic_attach_args structure as the id given by the controler.

If said id is "set" (e.g., it's a string and it's not NUL[L?]), a
driver's match function knows it's a direct config attempt and will use
said id to match.  If it isn't set, then it's an indirect config
attempt, and the driver will probe the usual way.

It gets ugly here because what we really want to avoid, whether the bus
be isa or icc, is a driver poking to some random address when not asked
to.  Which means that under the method given here, all drivers have to
be modified, most of them not to do anything but return 0 when a direct
config is attempted.

(Therefore, with a more refined autoconf(9), a driver would have a
match function for direct configuration, and a different one for
indirect configuration, more correctly called "probe function".)

In any case, cfdata_t are basically lines in the config files or its
equivalent for a LKM, but nothing more.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

--KlAEzMkarCnErv5Q
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iQEVAwUBRxoMC9goQloHrPnoAQJCHgf8Drt6k0eHv5a6HR7KKJ8oCqcGX3hq4QyT
3aZf+R1C1QQlDxfKH6P6agaFunlrm+SheHsKsYi/hJIsCwXBmZj/fPQKHbU771lL
jXuBd2uH2rgDY8udJY2Xx4FGHL64eIQP/PgRKQzT69Rjuf7hDt2GpD+XNLe7qIcH
6O7iH1VvmwwlXZMLkwPuneUNvDhIflYz7yJ+SzBswlrzcy/rZqrBdVRSZZBE0P+Y
bDviWEx2sTnosiPqfgFwjPljx7U0HX+HkYUvTIO5F4Eu3Nev7cDvQLol7wSQXChw
9QyujIh+e6odnvAMAYP3eBWtFegptcCFjA8DPsa2VPNt8JOQfZs6ug==
=v1e5
-----END PGP SIGNATURE-----

--KlAEzMkarCnErv5Q--