Failed to get irq using name is NOT fatal as driver will use index
to get irq instead, use platform_get_irq_byname_optional() instead
of platform_get_irq_byname() to avoid below error message during
probe:
[ 0.819312] fec 30be0000.ethernet: IRQ int0 not found
[ 0.824433] fec 30be0000.ethernet: IRQ int1 not found
[ 0.829539] fec 30be0000.ethernet: IRQ int2 not found
Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: Anson Huang <[email protected]>
---
drivers/net/ethernet/freescale/fec_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index d4d4c72..22c01b2 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3558,7 +3558,7 @@ fec_probe(struct platform_device *pdev)
for (i = 0; i < irq_cnt; i++) {
snprintf(irq_name, sizeof(irq_name), "int%d", i);
- irq = platform_get_irq_byname(pdev, irq_name);
+ irq = platform_get_irq_byname_optional(pdev, irq_name);
if (irq < 0)
irq = platform_get_irq(pdev, i);
if (irq < 0) {
--
2.7.4
Use platform_get_irq_byname_optional() and platform_get_irq_optional()
instead of platform_get_irq_byname() and platform_get_irq() for optional
IRQs to avoid below error message during probe:
[ 0.795803] fec 30be0000.ethernet: IRQ pps not found
[ 0.800787] fec 30be0000.ethernet: IRQ index 3 not found
Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: Anson Huang <[email protected]>
---
drivers/net/ethernet/freescale/fec_ptp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
index 19e2365..945643c 100644
--- a/drivers/net/ethernet/freescale/fec_ptp.c
+++ b/drivers/net/ethernet/freescale/fec_ptp.c
@@ -600,9 +600,9 @@ void fec_ptp_init(struct platform_device *pdev, int irq_idx)
INIT_DELAYED_WORK(&fep->time_keep, fec_time_keep);
- irq = platform_get_irq_byname(pdev, "pps");
+ irq = platform_get_irq_byname_optional(pdev, "pps");
if (irq < 0)
- irq = platform_get_irq(pdev, irq_idx);
+ irq = platform_get_irq_optional(pdev, irq_idx);
/* Failure to get an irq is not fatal,
* only the PTP_CLOCK_PPS clock events should stop
*/
--
2.7.4
From: Anson Huang <[email protected]> Sent: Wednesday, October 9, 2019 6:16 PM
> Use platform_get_irq_byname_optional() and platform_get_irq_optional()
> instead of platform_get_irq_byname() and platform_get_irq() for optional
> IRQs to avoid below error message during probe:
>
> [ 0.795803] fec 30be0000.ethernet: IRQ pps not found
> [ 0.800787] fec 30be0000.ethernet: IRQ index 3 not found
>
> Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to
> platform_get_irq*()")
> Signed-off-by: Anson Huang <[email protected]>
Acked-by: Fugang Duan <[email protected]>
> ---
> drivers/net/ethernet/freescale/fec_ptp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_ptp.c
> b/drivers/net/ethernet/freescale/fec_ptp.c
> index 19e2365..945643c 100644
> --- a/drivers/net/ethernet/freescale/fec_ptp.c
> +++ b/drivers/net/ethernet/freescale/fec_ptp.c
> @@ -600,9 +600,9 @@ void fec_ptp_init(struct platform_device *pdev, int
> irq_idx)
>
> INIT_DELAYED_WORK(&fep->time_keep, fec_time_keep);
>
> - irq = platform_get_irq_byname(pdev, "pps");
> + irq = platform_get_irq_byname_optional(pdev, "pps");
> if (irq < 0)
> - irq = platform_get_irq(pdev, irq_idx);
> + irq = platform_get_irq_optional(pdev, irq_idx);
> /* Failure to get an irq is not fatal,
> * only the PTP_CLOCK_PPS clock events should stop
> */
> --
> 2.7.4
From: Anson Huang <[email protected]> Sent: Wednesday, October 9, 2019 6:16 PM
> Failed to get irq using name is NOT fatal as driver will use index to get irq
> instead, use platform_get_irq_byname_optional() instead of
> platform_get_irq_byname() to avoid below error message during
> probe:
>
> [ 0.819312] fec 30be0000.ethernet: IRQ int0 not found
> [ 0.824433] fec 30be0000.ethernet: IRQ int1 not found
> [ 0.829539] fec 30be0000.ethernet: IRQ int2 not found
>
> Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to
> platform_get_irq*()")
> Signed-off-by: Anson Huang <[email protected]>
Acked-by: Fugang Duan <[email protected]>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index d4d4c72..22c01b2 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -3558,7 +3558,7 @@ fec_probe(struct platform_device *pdev)
>
> for (i = 0; i < irq_cnt; i++) {
> snprintf(irq_name, sizeof(irq_name), "int%d", i);
> - irq = platform_get_irq_byname(pdev, irq_name);
> + irq = platform_get_irq_byname_optional(pdev, irq_name);
> if (irq < 0)
> irq = platform_get_irq(pdev, i);
> if (irq < 0) {
> --
> 2.7.4
Quoting Anson Huang (2019-10-09 03:15:47)
> Failed to get irq using name is NOT fatal as driver will use index
> to get irq instead, use platform_get_irq_byname_optional() instead
> of platform_get_irq_byname() to avoid below error message during
> probe:
>
> [ 0.819312] fec 30be0000.ethernet: IRQ int0 not found
> [ 0.824433] fec 30be0000.ethernet: IRQ int1 not found
> [ 0.829539] fec 30be0000.ethernet: IRQ int2 not found
>
> Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
> Signed-off-by: Anson Huang <[email protected]>
> ---
Reviewed-by: Stephen Boyd <[email protected]>
Quoting Anson Huang (2019-10-09 03:15:48)
> Use platform_get_irq_byname_optional() and platform_get_irq_optional()
> instead of platform_get_irq_byname() and platform_get_irq() for optional
> IRQs to avoid below error message during probe:
>
> [ 0.795803] fec 30be0000.ethernet: IRQ pps not found
> [ 0.800787] fec 30be0000.ethernet: IRQ index 3 not found
>
> Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
> Signed-off-by: Anson Huang <[email protected]>
> ---
Reviewed-by: Stephen Boyd <[email protected]>
On Wed, 9 Oct 2019 18:15:47 +0800, Anson Huang wrote:
> Failed to get irq using name is NOT fatal as driver will use index
> to get irq instead, use platform_get_irq_byname_optional() instead
> of platform_get_irq_byname() to avoid below error message during
> probe:
>
> [ 0.819312] fec 30be0000.ethernet: IRQ int0 not found
> [ 0.824433] fec 30be0000.ethernet: IRQ int1 not found
> [ 0.829539] fec 30be0000.ethernet: IRQ int2 not found
>
> Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
> Signed-off-by: Anson Huang <[email protected]>
Hi Anson,
looks like there may be some dependency which haven't landed in the
networking tree yet? Because this doesn't build:
drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_probe’:
drivers/net/ethernet/freescale/fec_main.c:3561:9: error: implicit declaration of function ‘platform_get_irq_byname_optional’; did you mean ‘platform_get_irq_optional’? [-Werror=implicit-function-declaration]
3561 | irq = platform_get_irq_byname_optional(pdev, irq_name);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| platform_get_irq_optional
cc1: some warnings being treated as errors
Could you please repost once that's resolved? Please add Andy's and
Stephen's acks when reposting.
Thank you!
Hi, Jakub
> On Wed, 9 Oct 2019 18:15:47 +0800, Anson Huang wrote:
> > Failed to get irq using name is NOT fatal as driver will use index to
> > get irq instead, use platform_get_irq_byname_optional() instead of
> > platform_get_irq_byname() to avoid below error message during
> > probe:
> >
> > [ 0.819312] fec 30be0000.ethernet: IRQ int0 not found
> > [ 0.824433] fec 30be0000.ethernet: IRQ int1 not found
> > [ 0.829539] fec 30be0000.ethernet: IRQ int2 not found
> >
> > Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to
> > platform_get_irq*()")
> > Signed-off-by: Anson Huang <[email protected]>
>
> Hi Anson,
>
> looks like there may be some dependency which haven't landed in the
> networking tree yet? Because this doesn't build:
>
> drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_probe’:
> drivers/net/ethernet/freescale/fec_main.c:3561:9: error: implicit declaration
> of function ‘platform_get_irq_byname_optional’; did you mean
> ‘platform_get_irq_optional’? [-Werror=implicit-function-declaration]
> 3561 | irq = platform_get_irq_byname_optional(pdev, irq_name);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | platform_get_irq_optional
> cc1: some warnings being treated as errors
>
> Could you please repost once that's resolved? Please add Andy's and
> Stephen's acks when reposting.
>
> Thank you!
Sorry, I did this patch set based on linux-next tree, the below patch is landing
on Linux-next tree on Oct 5th, so maybe network tree is NOT sync with Linux-next tree?
I saw many other similar patches are already landing on Linux-next tree also, so what
do you suggest I should do? Or can you sync the network tree with Linux-next tree first? I do
NOT know the rule/schedule of network tree update to Linux-next.
commit f1da567f1dc1b55d178b8f2d0cfe8353858aac19
Author: Hans de Goede <[email protected]>
Date: Sat Oct 5 23:04:47 2019 +0200
driver core: platform: Add platform_get_irq_byname_optional()
thanks,
Anson
On Fri, 11 Oct 2019 00:03:22 +0000, Anson Huang wrote:
> > On Wed, 9 Oct 2019 18:15:47 +0800, Anson Huang wrote:
> > > Failed to get irq using name is NOT fatal as driver will use index to
> > > get irq instead, use platform_get_irq_byname_optional() instead of
> > > platform_get_irq_byname() to avoid below error message during
> > > probe:
> > >
> > > [ 0.819312] fec 30be0000.ethernet: IRQ int0 not found
> > > [ 0.824433] fec 30be0000.ethernet: IRQ int1 not found
> > > [ 0.829539] fec 30be0000.ethernet: IRQ int2 not found
> > >
> > > Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to
> > > platform_get_irq*()")
> > > Signed-off-by: Anson Huang <[email protected]>
> >
> > Hi Anson,
> >
> > looks like there may be some dependency which haven't landed in the
> > networking tree yet? Because this doesn't build:
> >
> > drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_probe’:
> > drivers/net/ethernet/freescale/fec_main.c:3561:9: error: implicit declaration
> > of function ‘platform_get_irq_byname_optional’; did you mean
> > ‘platform_get_irq_optional’? [-Werror=implicit-function-declaration]
> > 3561 | irq = platform_get_irq_byname_optional(pdev, irq_name);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > | platform_get_irq_optional
> > cc1: some warnings being treated as errors
> >
> > Could you please repost once that's resolved? Please add Andy's and
> > Stephen's acks when reposting.
> >
> > Thank you!
>
> Sorry, I did this patch set based on linux-next tree, the below patch is landing
> on Linux-next tree on Oct 5th, so maybe network tree is NOT sync with Linux-next tree?
linux-next is an integration tree, which merges all development trees
together to help with conflict resolution. Subsystem maintainers never
pull from it.
> I saw many other similar patches are already landing on Linux-next tree also, so what
> do you suggest I should do? Or can you sync the network tree with Linux-next tree first? I do
> NOT know the rule/schedule of network tree update to Linux-next.
>
> commit f1da567f1dc1b55d178b8f2d0cfe8353858aac19
> Author: Hans de Goede <[email protected]>
> Date: Sat Oct 5 23:04:47 2019 +0200
>
> driver core: platform: Add platform_get_irq_byname_optional()
Hm. Looks like the commit you need is commit f1da567f1dc1 ("driver core:
platform: Add platform_get_irq_byname_optional()") and it's currently
in Greg's tree. You have to wait for that commit to make its way into
Linus'es main tree and then for Dave Miller to pull from Linus.
I'd suggest you check if your patches builds on the net tree:
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
once a week. My guess is it'll probably take two weeks or so for
Greg's patches to propagate to Dave.
Hi, Jakub
> On Fri, 11 Oct 2019 00:03:22 +0000, Anson Huang wrote:
> > > On Wed, 9 Oct 2019 18:15:47 +0800, Anson Huang wrote:
> > > > Failed to get irq using name is NOT fatal as driver will use index
> > > > to get irq instead, use platform_get_irq_byname_optional() instead
> > > > of
> > > > platform_get_irq_byname() to avoid below error message during
> > > > probe:
> > > >
> > > > [ 0.819312] fec 30be0000.ethernet: IRQ int0 not found
> > > > [ 0.824433] fec 30be0000.ethernet: IRQ int1 not found
> > > > [ 0.829539] fec 30be0000.ethernet: IRQ int2 not found
> > > >
> > > > Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message
> > > > to
> > > > platform_get_irq*()")
> > > > Signed-off-by: Anson Huang <[email protected]>
> > >
> > > Hi Anson,
> > >
> > > looks like there may be some dependency which haven't landed in the
> > > networking tree yet? Because this doesn't build:
> > >
> > > drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_probe’:
> > > drivers/net/ethernet/freescale/fec_main.c:3561:9: error: implicit
> > > declaration of function ‘platform_get_irq_byname_optional’; did you
> > > mean ‘platform_get_irq_optional’? [-Werror=implicit-function-
> declaration]
> > > 3561 | irq = platform_get_irq_byname_optional(pdev, irq_name);
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > | platform_get_irq_optional
> > > cc1: some warnings being treated as errors
> > >
> > > Could you please repost once that's resolved? Please add Andy's and
> > > Stephen's acks when reposting.
> > >
> > > Thank you!
> >
> > Sorry, I did this patch set based on linux-next tree, the below patch
> > is landing on Linux-next tree on Oct 5th, so maybe network tree is NOT sync
> with Linux-next tree?
>
> linux-next is an integration tree, which merges all development trees
> together to help with conflict resolution. Subsystem maintainers never pull
> from it.
>
> > I saw many other similar patches are already landing on Linux-next
> > tree also, so what do you suggest I should do? Or can you sync the
> > network tree with Linux-next tree first? I do NOT know the rule/schedule of
> network tree update to Linux-next.
> >
> > commit f1da567f1dc1b55d178b8f2d0cfe8353858aac19
> > Author: Hans de Goede <[email protected]>
> > Date: Sat Oct 5 23:04:47 2019 +0200
> >
> > driver core: platform: Add platform_get_irq_byname_optional()
>
> Hm. Looks like the commit you need is commit f1da567f1dc1 ("driver core:
> platform: Add platform_get_irq_byname_optional()") and it's currently in
> Greg's tree. You have to wait for that commit to make its way into Linus'es
> main tree and then for Dave Miller to pull from Linus.
>
> I'd suggest you check if your patches builds on the net tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
>
> once a week. My guess is it'll probably take two weeks or so for Greg's
> patches to propagate to Dave.
Thanks for explanation of how these trees work, so could you please wait the necessary
patch landing on network tree then apply this patch series, thanks for help.
Anson.
On Fri, 11 Oct 2019 00:38:50 +0000, Anson Huang wrote:
> > Hm. Looks like the commit you need is commit f1da567f1dc1 ("driver core:
> > platform: Add platform_get_irq_byname_optional()") and it's currently in
> > Greg's tree. You have to wait for that commit to make its way into Linus'es
> > main tree and then for Dave Miller to pull from Linus.
> >
> > I'd suggest you check if your patches builds on the net tree:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> >
> > once a week. My guess is it'll probably take two weeks or so for Greg's
> > patches to propagate to Dave.
>
> Thanks for explanation of how these trees work, so could you please
> wait the necessary patch landing on network tree then apply this
> patch series, thanks for help.
Unfortunately the networking subsystem sees around a 100 patches
submitted each day, it'd be very hard to keep track of patches which
have external dependencies and when to merge them. That's why we need
the submitters to do this work for us and resubmit when the patch can
be applied cleanly.
Hi, Jakub
> On Fri, 11 Oct 2019 00:38:50 +0000, Anson Huang wrote:
> > > Hm. Looks like the commit you need is commit f1da567f1dc1 ("driver core:
> > > platform: Add platform_get_irq_byname_optional()") and it's
> > > currently in Greg's tree. You have to wait for that commit to make
> > > its way into Linus'es main tree and then for Dave Miller to pull from Linus.
> > >
> > > I'd suggest you check if your patches builds on the net tree:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> > >
> > > once a week. My guess is it'll probably take two weeks or so for
> > > Greg's patches to propagate to Dave.
> >
> > Thanks for explanation of how these trees work, so could you please
> > wait the necessary patch landing on network tree then apply this patch
> > series, thanks for help.
>
> Unfortunately the networking subsystem sees around a 100 patches
> submitted each day, it'd be very hard to keep track of patches which have
> external dependencies and when to merge them. That's why we need the
> submitters to do this work for us and resubmit when the patch can be
> applied cleanly.
OK, I will resend this patch series once the necessary patch lands on the network
tree.
Thanks,
Anson
Hi Anson,
On Fri, 11 Oct 2019 at 04:11, Anson Huang <[email protected]> wrote:
>
> Hi, Jakub
>
> > On Fri, 11 Oct 2019 00:38:50 +0000, Anson Huang wrote:
> > > > Hm. Looks like the commit you need is commit f1da567f1dc1 ("driver core:
> > > > platform: Add platform_get_irq_byname_optional()") and it's
> > > > currently in Greg's tree. You have to wait for that commit to make
> > > > its way into Linus'es main tree and then for Dave Miller to pull from Linus.
> > > >
> > > > I'd suggest you check if your patches builds on the net tree:
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> > > >
> > > > once a week. My guess is it'll probably take two weeks or so for
> > > > Greg's patches to propagate to Dave.
> > >
> > > Thanks for explanation of how these trees work, so could you please
> > > wait the necessary patch landing on network tree then apply this patch
> > > series, thanks for help.
> >
> > Unfortunately the networking subsystem sees around a 100 patches
> > submitted each day, it'd be very hard to keep track of patches which have
> > external dependencies and when to merge them. That's why we need the
> > submitters to do this work for us and resubmit when the patch can be
> > applied cleanly.
>
> OK, I will resend this patch series once the necessary patch lands on the network
> tree.
What has not been mentioned is that you can't create future
dependencies for patches which have a Fixes: tag.
git describe --tags 7723f4c5ecdb # driver core: platform: Add an error
message to platform_get_irq*()
v5.3-rc1-13-g7723f4c5ecdb
git describe --tags f1da567f1dc # driver core: platform: Add
platform_get_irq_byname_optional()
v5.4-rc1-46-gf1da567f1dc1
So you have to consider whether the patch is really fixing anything
(it is only getting rid of a non-fatal error message).
And it's not reasonable anyway to say that you're fixing the patch
that added the error message in the generic framework.
The fallback logic has always been there in the driver. So you might
want to drop the Fixes: tag when you resend.
>
> Thanks,
> Anson
Regards,
-Vladimir
Hi, Vladimir
> On Fri, 11 Oct 2019 at 04:11, Anson Huang <[email protected]> wrote:
> >
> > Hi, Jakub
> >
> > > On Fri, 11 Oct 2019 00:38:50 +0000, Anson Huang wrote:
> > > > > Hm. Looks like the commit you need is commit f1da567f1dc1 ("driver
> core:
> > > > > platform: Add platform_get_irq_byname_optional()") and it's
> > > > > currently in Greg's tree. You have to wait for that commit to
> > > > > make its way into Linus'es main tree and then for Dave Miller to pull
> from Linus.
> > > > >
> > > > > I'd suggest you check if your patches builds on the net tree:
> > > > >
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> > > > >
> > > > > once a week. My guess is it'll probably take two weeks or so for
> > > > > Greg's patches to propagate to Dave.
> > > >
> > > > Thanks for explanation of how these trees work, so could you
> > > > please wait the necessary patch landing on network tree then apply
> > > > this patch series, thanks for help.
> > >
> > > Unfortunately the networking subsystem sees around a 100 patches
> > > submitted each day, it'd be very hard to keep track of patches which
> > > have external dependencies and when to merge them. That's why we
> > > need the submitters to do this work for us and resubmit when the
> > > patch can be applied cleanly.
> >
> > OK, I will resend this patch series once the necessary patch lands on
> > the network tree.
>
> What has not been mentioned is that you can't create future dependencies
> for patches which have a Fixes: tag.
>
> git describe --tags 7723f4c5ecdb # driver core: platform: Add an error
> message to platform_get_irq*() v5.3-rc1-13-g7723f4c5ecdb
>
> git describe --tags f1da567f1dc # driver core: platform: Add
> platform_get_irq_byname_optional()
> v5.4-rc1-46-gf1da567f1dc1
>
> So you have to consider whether the patch is really fixing anything (it is only
> getting rid of a non-fatal error message).
> And it's not reasonable anyway to say that you're fixing the patch that added
> the error message in the generic framework.
> The fallback logic has always been there in the driver. So you might want to
> drop the Fixes: tag when you resend.
OK, I agree that such kind of patch should NOT add fix tag, but I was confused when
I created this patch, as I saw many similar patches also has fix tag, such as below 2
examples.
I will drop the fix tag when resend the patch series.
commit 71eea7071583b04e9b796ee1d6f7a07334426495
Author: Andy Shevchenko <[email protected]>
Date: Thu Oct 10 11:15:20 2019 +0300
platform/x86: intel_punit_ipc: Avoid error message when retrieving IRQ
Since the commit
7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
the platform_get_irq() started issuing an error message which is not
what we want here.
Switch to platform_get_irq_optional() to have only warning message
provided by the driver.
Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: Andy Shevchenko <[email protected]>
drivers/platform/x86/intel_punit_ipc.c
commit 392fb8df528b97a06e19312772afd38aec542b96
Author: Geert Uytterhoeven <[email protected]>
Date: Tue Oct 1 20:07:43 2019 +0200
serial: sh-sci: Use platform_get_irq_optional() for optional interrupts
As platform_get_irq() now prints an error when the interrupt does not
exist, scary warnings may be printed for optional interrupts:
sh-sci e6550000.serial: IRQ index 1 not found
sh-sci e6550000.serial: IRQ index 2 not found
sh-sci e6550000.serial: IRQ index 3 not found
sh-sci e6550000.serial: IRQ index 4 not found
sh-sci e6550000.serial: IRQ index 5 not found
Fix this by calling platform_get_irq_optional() instead for all but the
first interrupts, which are optional.
Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Reviewed-by: Yoshihiro Shimoda <[email protected]>
Tested-by: Yoshihiro Shimoda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
drivers/tty/serial/sh-sci.c
thanks,
Anson
On Fri, 11 Oct 2019 12:55:20 +0300, Vladimir Oltean wrote:
> > > Unfortunately the networking subsystem sees around a 100 patches
> > > submitted each day, it'd be very hard to keep track of patches which have
> > > external dependencies and when to merge them. That's why we need the
> > > submitters to do this work for us and resubmit when the patch can be
> > > applied cleanly.
> >
> > OK, I will resend this patch series once the necessary patch lands
> > on the network tree.
>
> What has not been mentioned is that you can't create future
> dependencies for patches which have a Fixes: tag.
>
> git describe --tags 7723f4c5ecdb # driver core: platform: Add an error
> message to platform_get_irq*()
> v5.3-rc1-13-g7723f4c5ecdb
>
> git describe --tags f1da567f1dc # driver core: platform: Add
> platform_get_irq_byname_optional()
> v5.4-rc1-46-gf1da567f1dc1
Ack, you raise some good points. AFAIU tho, in this case broken
patch, the dependency, and the fix are all targeting 5.4, so there
will be no real backporting hassle, while the presence of a Fixes
tag makes it clear where the regression was introduced.