Re: UART question

On Tue, Jul 08, 2025 at 03:34:20PM +0000, Vincent DEFERT wrote:
> > What I will be happy to learn too, is the articulation between the
> > config and the DTB: there may be nodes created because some device is
> > declared in the config, while being, also, described in the DTB; but
> > some devices only declared in the DTB will escape the detection.
> > 
> > Has the DTB to be mirrored in some way in the config? This is the
> > question for which I didn't search an answer in the sources...
> The config lists the drivers to compile into the kernel and each driver has
> a list of "compatible" strings that are checked against those in the DTB
> when the driver's "match" function is invoked by the kernel.
> Only the DTB nodes with their "status" property set to "okay" are submitted
> to the match function.
> For every match, the driver's "attach" function is invoked so it can use the
> information provided by the corresponding DTB node to configure a device
> instance.
> After configuring the hardware, the driver's "attach" function must call the
> relevant attach kernel API so the kernel becomes aware of the new device
> instance and knows how to call its methods.
> This can be tty_attach() for an UART, fdtbus_register_i2c_controller() +
> fdtbus_attach_i2cbus() for an I2C interface, or
> sysmon_envsys_sensor_attach() + sysmon_envsys_register() for a temperature
> sensor or an ADC.
> You get the idea.

Thank you for the explanation!

So, concerning removing the leaves on /dev (in fact, from another
message, suppressing /dev/console would be enough), the nodes are
created in a ramfs but exactly in the same way as with the
static/classical /dev populated by MAKEDEV ---the advantage with the
ramfs being that one can try to have / read-only or mainly read-only,
and /dev not put in a SD in order to avoid wearing-out the storage.

But, contrary to what I thought, this doesn't limit the nodes to what
does exist.

And the advantage of having devices appearing (named) in the
filesystem (/dev) only if they exist is that one can see at a glance
what is here and, failing that, what is not.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C