linux-kernel - RE: [PATCH] tty: serial: imx: Only get second/third IRQ when there is more than one IRQ

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: <DB3PR0402MB391677227A688D5DD56A8417F5950@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Date:   Wed, 9 Oct 2019 07:43:24 +0000
From:   Anson Huang <anson.huang@....com>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
CC:     Stephen Boyd <swboyd@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "jslaby@...e.com" <jslaby@...e.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: RE: [PATCH] tty: serial: imx: Only get second/third IRQ when there is
 more than one IRQ

Hi, Uwe

> On Wed, Oct 09, 2019 at 07:24:57AM +0000, Anson Huang wrote:
> > > On Wed, Oct 09, 2019 at 06:58:24AM +0000, Anson Huang wrote:
> > > > > The patch is fine given the changed behaviour of
> > > > > platform_get_irq. I wonder if it is sensible to introduce a
> > > > > variant of platform_get_irq (say
> > > > > platform_get_irq_nowarn) that behaves like __platform_get_irq
> > > > > does t Then the imx driver would just call
> > > > > platform_get_irq_nowarn without having to check the number of
> available irqs first.
> > > >
> > > > Agreed, it would be nice if we can fix this from the API level,
> > > > this is to save many patches from various drivers side, let me
> > > > know if agreement is reached and I will do the patch.
> > >
> > > I wouldn't expect that most callers actually want an error message
> > > and so these need a different patch (i.e. dropping the error message by
> the caller).
> > > This type of patch is fine and the normal load when something is
> > > consolidated.
> > >
> > > Which other drivers do you have on your radar that don't want an
> > > error message if platform_get_irq() fails?
> >
> > I did NOT mean drivers don't want an error when getting irq failed,
> > but I just agree that introducing another API with nowarn as you
> > mentioned upper, then i.MX driver can call it. For now, the FEC driver
> > also have many such error message, we will fix later.
> >
> > So if the API with nowarn is added, then I can change the API call in
> > some i.MX driver instead of getting irq_count first. Do you think I
> > should add the nowarn API and redo this patch to call it?
> 
> Having a patch (or a set of patches) is probably helpful to get forward here,
> yes. You have my blessing to create a suggestion. (Not that you actually need
> that :-)

Thanks, OK, then I will leave this patch as it is for now, and leave others to decide whether
to add a patch of adding new API of nowarn. Some drivers need to be changed anyway to avoid
this error message, either getting irq count first or calling new API once it is added.

Thanks,
Anson