[PATCH v1 3/5] tty: serial: meson: apply ttyS devname instead of ttyAML for new SoCs

[Conor Dooley]

On Tue, Jul 04, 2023 at 08:13:26PM +0300, Dmitry Rokosov wrote:
> On Tue, Jul 04, 2023 at 05:57:15PM +0100, Conor Dooley wrote:
> > On Tue, Jul 04, 2023 at 04:59:34PM +0300, Dmitry Rokosov wrote:
> > > It is worth noting that the devname ttyS is a widely recognized tty name
> > > and is commonly used by many uart device drivers. Given the established
> > > usage and compatibility concerns, it may not be feasible to change the
> > > devname for older SoCs. However, for new definitions, it is acceptable
> > > and even recommended to use a new devname to help ensure clarity and
> > > avoid any potential conflicts on lower or upper software levels.
> > 
> > > In
> > > addition, modify the meson_uart_dt match data for g12a, a1, and s4 to
> > > their appropriate values to ensure proper devname values and
> > > functionality.
> > 
> > IMO, this is a separate change that should be in another patch, had to
> > go looking through a several of unrelated $subject patches to understand
> > how the binding patch was going to work.
> 
> I apologize, but I'm having difficulty understanding your suggestion.
> Are you recommending that a distinct binding patch for meson-uart-a1 be
> sent as part of a separate patch series? From my perspective, isolating
> the binding patch may not provide all the necessary context as it is
> reliant on a separate 'compatible' declaration within the meson-uart
> driver. However, this declaration is interconnected with the devname
> support patchset. Therefore, it seems that all of these patches are
> linked together.

Maybe it is just a case of how the commit message was written, where the
SoCs responsible for the changes appear only "in addition". At the
moment, it seemed like an unrelated addition that was sneaking into the
commit to me, who was trying to find the code change that made the DT
side of things valid,

Re-phrasing the commit message to explain that the a1 is the reason for
this change, rather than mentioning the SoCs as an apparent afterthought
would make sense to me here. As would splitting reworking the code to
support devname stuff in one commit & adding the new match for the a1 in
another. Whatever works for you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230704/cd056821/attachment.sig>