Re: [PATCH v2] ns16550: add support for polling mode when device tree is used

[Julien Grall <julien@xxxxxxx>]

Hi,

On 18/07/2023 16:00, Oleksii wrote:
> On Tue, 2023-07-18 at 15:23 +0100, Julien Grall wrote:
> > On 18/07/2023 15:13, Oleksii Kurochko wrote:
> > > RISC-V doesn't support interrupts for the time being, so it would
> > > be nice to
> > > have polling mode.
> > >
> > > The patch assumes that polling mode will be used if there is no
> > > interrupt
> > > property
> > As I asked in v1, please explain that this is allowed by the binding
> > and
> > provide a link for others to verify.
> According to 4.2.2 National Semiconductor 16450/16550 Compatible UART
> Requirements from The Devicetree Specification v0.4
> ( https://www.devicetree.org/specifications/ ) interrupts property
> should always present.
I don't read the spec the same way as you. The property is marked as 
'OR' which means the property is optional but recommended.
Therefore, what you just wrote is enough to justify why we can relax the 
check.
> > > or the interrupt is equal to some unused UART interrupt number (
> > > look
> > > at the definition of NO_IRQ_POLL in ns16550.c ).
> > Nack. If you want to use polling mode and yet have an interrupts
> > property then you should provide the information differently. This
> > would
> > either be via the command line or an extra property in the DT node.
> >
> > If the latter, it would need to be standardized first.
> What does it mean 'standardized'? Do you mean that it should updated
> The Devicetree Specification?
I mean that the binding for the ns16550 in 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings 
should be updated.
I will not accept any code in Xen which use properties that have not 
been accepted by the Linux/Device-Tree community. Unless this is a 
binding "owned" by Xen (e.g. the nodes for dom0less).
> I am not sure that I know the process of standardization of such stuff
> could you please give me any pointers?
In general, this is sending an e-mail to the device-tree mailing with 
your proposal in the form of a patch.
> It looks like it will be faster to pass it via the command line as
> standardization can consume some time...
Well yes. But as usual, it depends on your end goal. For instance, we 
would not want to describe the HW on the command line.
Thinking a bit more, in this case, the command line option is probably 
best because you want to override what's describe in the firmware table.
Cheers,

--
Julien Grall