From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
To: linux-aspeed@lists.ozlabs.org
Subject: [PATCH 000/117] media: Convert to platform remove callback returning void
Date: Mon, 17 Apr 2023 08:02:03 +0200 [thread overview]
Message-ID: <20230417060203.le3izz56wt73si6k@pengutronix.de> (raw)
In-Reply-To: <20230326143224.572654-1-u.kleine-koenig@pengutronix.de>
Hello Mauro
On Sun, Mar 26, 2023 at 04:30:25PM +0200, Uwe Kleine-K?nig wrote:
> Hello,
>
> this series adapts the platform drivers below drivers/pci to use the
copy&paste failure here: s/pci/media/ of course.
> .remove_new() callback. Compared to the traditional .remove() callback
> .remove_new() returns no value. This is a good thing because the driver core
> doesn't (and cannot) cope for errors during remove. The only effect of a
> non-zero return value in .remove() is that the driver core emits a warning. The
> device is removed anyhow and an early return from .remove() usually yields a
> resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably assume any more that there is some kind of cleanup later.
>
> Only three drivers needed some preparation first to make sure they
> return 0 unconditionally in their remove callback. Then all drivers
> could be trivially converted without side effects to .remove_new().
>
> The changes to the individual drivers are all orthogonal. If I need to
> resend some patches because of some review feedback, I'd like to only
> send the patches that actually needed changes, so please pick up the
> remaining patches that don't need changing to reduce the amount of mail.
I didn't hear anything back about application of this series. Is there a
blocker somewhere?
Apart from the three preparatory patches that are a precondition to the
conversion of the respective drivers, the patches are all pairwise
orthogonal. So from my POV the best would be to apply all patches that
still apply (which might be all), I will care for the fallout later
then.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230417/95f49a3c/attachment-0001.sig>
next prev parent reply other threads:[~2023-04-17 6:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-26 14:30 [PATCH 000/117] media: Convert to platform remove callback returning void Uwe Kleine-König
2023-03-26 14:30 ` [PATCH 017/117] media: aspeed-video: " Uwe Kleine-König
2023-04-17 6:02 ` Uwe Kleine-König [this message]
2023-04-17 6:19 ` [PATCH 000/117] media: " Laurent Pinchart
2023-04-17 7:30 ` Uwe Kleine-König
2023-04-17 7:35 ` Laurent Pinchart
2023-04-17 7:57 ` Biju Das
2023-04-17 8:54 ` Uwe Kleine-König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230417060203.le3izz56wt73si6k@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-aspeed@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox