Re: How do I choose an arbitrary minor number for my tty device?

From: Scott Wood
Date: Thu Nov 18 2010 - 13:15:18 EST


On Thu, 18 Nov 2010 11:42:21 -0600
Timur Tabi <timur@xxxxxxxxxxxxx> wrote:

> Scott Wood wrote:
>
> > The tty driver doesn't register the bus, but rather a driver for
> > some type of device on that bus. The code to create the bus goes
> > elsewhere, and would not be specific to byte channels.
>
> Which code to create the bus? Are you saying that the driver should call
> bus_register()?

No, the bus code calls that (probably drivers/base/platform.c in this
case).

> >> Also, this is an Open Firmware driver. I already have a mechanism whereby I get
> >> probed for each instance of a byte channel. Isn't that my "bus"?
> >
> > It would be if you actually had it -- but it looks like you just loop
> > over the nodes.
>
> Well, ok, but I can change that. If I drop the normal character driver
> registration and register the byte channels only as tty devices, then I can make
> it probe-able.

OK.

> > We should add a proper bus for the "handles" node. Then sysfs should
> > show the link between the tty device and a device tree node -- which is
> > really what we're after, the handle is just a means to that end.
>
> How exactly do I do that?

Pass the platform device pointer to tty_register_device.

Then, in the sysfs node, "driver" should be a symlink to
another sysfs node whose path looks lind of like an OF path.

Unfortunately, it's not an exact match, and the fact that reg doesn't
translate to a physical address means that AFAICT you'll currently get
something like "byte-channel.nnn", where "nnn" is an arbitrary
kernel-assigned number.

It would be nice if platform devices that are created from device tree
nodes included a link to the corresponding /proc/device-tree node in
their sysfs node.

Other than that, I guess you could add hv handle support to
of_device_make_bus_id.

-Scott

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/