[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <cover.1629472813.git.christophe.jaillet@wanadoo.fr>
Date: Fri, 20 Aug 2021 17:37:44 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: linus.walleij@...aro.org, bgolaszewski@...libre.com,
alexandru.marginean@....com, Laurentiu.Tudor@....com,
hui.song_1@....com, andy.shevchenko@...il.com, ran.wang_1@....com
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-janitors@...r.kernel.org,
Christophe JAILLET <christophe.jaillet@...adoo.fr>
Subject: [PATCH 0/3] gpio: mpc8xxx: Fix 3 errors related to the error handling path of the 'mpc8xxx_probe()'
This has been split in 3 patches because:
- the root issue of patch 1 and 3 is not the same commit as the one for patch 2.
- the strategy to fix the issues is not the same
- patch 1: add a new call in the rror handling path
- patch 3: switch to a resource managed function
They could be merged together if easier to review. The subject would then be
something like "gpio: mpc8xxx: Fix the error handling path of 'mpc8xxx_probe()'"
If prefered, 'devm_add_action_or_reset()' could be used to switch the probe to
a fully managed resource function and remove the 'remove' function.
That's mostly a matter of taste.
If such an option is preferred, I'm a bit puzzled by the
'irq_set_chained_handler_and_data()' call in the remove function because I
don't see why it is there.
Also see the comment at the end of patch 1 also related to this function call.
Christophe JAILLET (3):
gpio: mpc8xxx: Fix a resources leak in the error handling path of
'mpc8xxx_probe()'
gpio: mpc8xxx: Fix a potential double iounmap call in
'mpc8xxx_probe()'
gpio: mpc8xxx: Use 'devm_gpiochip_add_data()' to simplify the code and
avoid a leak
drivers/gpio/gpio-mpc8xxx.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
--
2.30.2
Powered by blists - more mailing lists