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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AS8PR05MB9810B543A1223ED04729EAAE83022@AS8PR05MB9810.eurprd05.prod.outlook.com>
Date: Mon, 23 Dec 2024 14:27:22 +0000
From: Maarten Brock <Maarten.Brock@...ls.nl>
To: Andre Werner <andre.werner@...tec-electronic.com>, Greg KH
	<gregkh@...uxfoundation.org>
CC: "jirislaby@...nel.org" <jirislaby@...nel.org>, "hvilleneuve@...onoff.com"
	<hvilleneuve@...onoff.com>, "andy@...nel.org" <andy@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	"lech.perczak@...lingroup.com" <lech.perczak@...lingroup.com>
Subject: RE: [External Email] Re: [PATCH] serial: sc16is7xx: Add polling
 feature if no IRQ usage possible

Hello Greg and Andre,

> From: Andre Werner <andre.werner@...tec-electronic.com>
> 
> 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@...tec-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 :)

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