On Thu, Feb 15, 2024 at 10:11 PM Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > Hello, > > On Wed, Jan 10, 2024 at 09:34:53AM +0100, Uwe Kleine-König wrote: > > On Mon, Dec 18, 2023 at 09:47:10PM +0100, Uwe Kleine-König wrote: > > > On Wed, Nov 22, 2023 at 06:49:13PM +0100, Borislav Petkov wrote: > > > > On Wed, Nov 22, 2023 at 04:25:30PM +0100, Rafael J. Wysocki wrote: > > > > > On Mon, Nov 20, 2023 at 6:31 PM Uwe Kleine-König > > > > > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > The .remove() callback for a platform driver returns an int which makes > > > > > > many driver authors wrongly assume it's possible to do error handling by > > > > > > returning an error code. However the value returned is ignored (apart > > > > > > from emitting a warning) and this typically results in resource leaks. > > > > > > > > > > > > To improve here there is a quest to make the remove callback return > > > > > > void. In the first step of this quest all drivers are converted to > > > > > > .remove_new(), which already returns void. Eventually after all drivers > > > > > > are converted, .remove_new() will be renamed to .remove(). > > > > > > > > > > > > Instead of returning an error code, emit a better error message than the > > > > > > core. Apart from the improved error message this patch has no effects > > > > > > for the driver. > > > > > > > > > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> > > > > > > --- > > > > > > Hello, > > > > > > > > > > > > I tried to improve this driver before, see > > > > > > > > > > > > https://lore.kernel.org/linux-acpi/CAJZ5v0ifb-wvyp0JRq_4c1L6vTi_qEeXJ6P=Pmmq_56xRL74_A@xxxxxxxxxxxxxx > > > > > > https://lore.kernel.org/linux-arm-kernel/20221219221439.1681770-1-u.kleine-koenig@xxxxxxxxxxxxxx > > > > > > https://lore.kernel.org/linux-arm-kernel/20221220154447.12341-1-u.kleine-koenig@xxxxxxxxxxxxxx > > > > > > > > > > > > but this didn't result in any patch being applied. > > > > > > > > > > > > I think it's inarguable that there is a problem that wants to be fixed. > > > > > > My tries to fix this problem fixxled out, so here comes a minimal change > > > > > > that just points out the problem and otherwise makes ghes_remove() > > > > > > return void without further side effects to allow me to continue my > > > > > > quest to make platform_driver remove callbacks return no error. > > > > > > > > > > Tony, Boris, any objections against this patch? > > > > > > > > SDEI is James. Moving him to To: > > > > > > I wonder if you had a chance to look at this patch. > > > > > > It doesn't change anything for the SDEI driver, the only effect is to > > > have one driver less using platform_driver's remove function. > > > > > > Would be great if that patch made it in. > > > > I guess it's to late for 6.8-rc1, but I wonder if this patch is still on > > your radar? > > I'm a frustrated about this patch. It already missed two merge windows > while it's (IMHO) easy to understand that it doesn't change anything > relevant for the driver. (There is a resource leak in this driver, the > only difference my patch makes here is that it's more visible than > before that the leak is there.) > > What must happen to make this patch go in? Well, I will just have to take it without an ACK. However, the lack of a (responsive) ARM reviewer for APEI/GHES needs to be sorted out. Thanks!
