Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs

From: Tomasz Figa
Date: Thu Jun 26 2014 - 08:02:54 EST


On 26.06.2014 13:39, Russell King - ARM Linux wrote:
> On Thu, Jun 26, 2014 at 01:24:32PM +0200, Tomasz Figa wrote:
>> Current Samsung UART driver relies on probe order of particular
>> samsung-uart instances, which makes it impossible to get proper
>> initialization of ports when not all ports are available on board,
>> not even saying of deterministic device naming.
>>
>> This series intends to fix this situation by adding support to parse
>> aliases from device tree and use them to assign instance IDs to
>> particular port instances.
>
> How about instead exporting the path/id information so that userspace
> can create /dev/serial/by-{path,id}/... for internal devices instead?
>
> The problem you're raising is very much the same problem you have when
> there are multiple USB serial devices connected to the machine - you
> just get a bunch of /dev/ttyUSB* devices which are unordered (they can
> change on each boot, or change order if you disconnect and reconnect
> them.)
>
> /dev/serial/by-{path,id}/ allows for a much more stable path.
>

The problem being solved has slightly different constraints than the one
with USB serials you mentioned:

- basically Samsung UART already has its own namespace (ttySAC) and the
order inside it is well-defined - instance ID shall be the hardware
instance number as specified by documentation. The ports vary in certain
aspects and the ID is important knowledge of the driver. The problem
here was broken implementation of assigning IDs based on probe order,
which worked only because on all Exynos platforms all ports have been
always registered (which we want to change now and keep unused ones
"disabled" in DT),

- we already have a lot of userspace depending on the aforementioned
ttySAC namespace and proper ordering of instances there. While I believe
the proper solution as of today would be to go back to standard ttyS
namespace and make userspace use a smarter way of identifying the
instances (e.g. by path or id, as you suggested), I don't think this
will make anyone's life easier with current assumptions,

- correct me if I'm wrong, but I don't think the
/dev/serial/by-{path,id} would be handled in kernel's console= parameter.

Best regards,
Tomasz
--
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/