Re: [External Email] Re: [PATCH] serial: sc16is7xx: Add polling feature if no IRQ usage possible

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Dec 19, 2024 at 10:22:40AM +0100, Andre Werner wrote:
> Dear Greg,
> On Thu, 19 Dec 2024, Greg KH wrote:
> 
> > On Thu, Dec 19, 2024 at 09:46:38AM +0100, Andre Werner wrote:
> > > Fall back to polling mode if no interrupt is configured because not
> > > possible. If "interrupts" property is missing in devicetree the driver
> > > uses a delayed worker to pull state of interrupt status registers.
> > >
> > > Signed-off-by: Andre Werner <andre.werner@systec-electronic.com>
> > > ---
> > > This driver was tested on Linux 5.10. We had a custom board that was not
> > > able to connect the interrupt port. Only I2C was available.
> >
> > Could you not test this on the latest tree?  5.10 is _VERY_ old now.
> 
> I will try it on devboard with a 6.1 Kernel. Is that okay for you?

6.1 was released in December of 2022, 2 full years and hundreds of
thousands of changes ago.  Please work off of Linus's latest tree, we
can't go back in time :)

> > > @@ -1537,7 +1564,13 @@ int sc16is7xx_probe(struct device *dev, const struct sc16is7xx_devtype *devtype,
> > >
> > >  	/* Always ask for fixed clock rate from a property. */
> > >  	device_property_read_u32(dev, "clock-frequency", &uartclk);
> > > +	s->polling = !device_property_present(dev, "interrupts");
> > >
> > > +	if (s->polling) {
> > > +		dev_warn(dev,
> > > +			 "No interrupt definition found. Falling back to polling mode.\n");
> >
> > What is a user supposed to do with this message?  And why would a device
> > NOT have any interrupts?  This feels like it is just going to pound on
> > the device and cause a lot of power drain for just a simple little uart.
> 
> I thought it could be interesting to know that the device has missing
> interrupt support.

Maybe, but as you are now warning a user about this, what are they
supposed to do to fix it?

> > Why can't your system provide a valid irq line?
> >
> 
> In our case we have only an I2C available in a connection cable and the
> GPIOs are linked through a two way level shifter.
> It was a very special situation in our case because target platform and
> sensor platform are provided.
> The IRQ from the sensor war not able to drive the two way level shifter low so
> we always detect outgoing traffic and the IRQ signal but at the target
> board after the level shifter the signal remains stable. So
> communication failed with a timeout. So we need to force polling the
> interrupt status register because
> both HW solution should not be changed in any way.

Again, you are burning a TON of power just for a simple little uart,
with your system never being able to go to sleep, are you sure this is
something that you want others to emulate and support?

thanks,

greg k-h