Dear Greg:
On Thu, 19 Dec 2024, Greg KH wrote:
> 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@xxxxxxxxxxxxxxxxxxxxx>
> > > > ---
> > > > 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?
I got your point and I'm fully with. This caused me to print a warning
in Kernel log because it should not be the general working method.
In our special case we do not have any other option because the sensor
module using the SC16IS7xx and the hardware with the MCU running Linux OS
are fixed. We had no possibilities to move any GPIO or such. This was
the only chance to support the dedicated sensor platform and I may be
the case that someone else faces the same problems. I thought that
someone else may benefit from this workaround too. But as I got your
point I'm also fine if it is not merged into main Linux Kernel sources.
>
> thanks,
>
> greg k-h
>
