Hello Greg and Andre, > From: Andre Werner <andre.werner@xxxxxxxxxxxxxxxxxxxxx> > > 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 :) I agree with Greg that such a new feature only belongs in the current development. > > > > > @@ -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? Again, I agree with Greg, this message is appropriate to the developer only. I suggest to change the log level. > > > > Why can't your system provide a valid irq line? Here, I am more with Andre. This just happens sometimes, esp. in embedded solutions. > > > 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? But the alternative is even worse: a non-functioning uart. Something that works but consumes too much power is better than something that doesn't even work at all. > 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. I vote this patch to go in (after modification). Kind regards, Maarten