On Thu, Feb 15, 2024 at 10:25 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > 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. So applied (as 6.9 material), but I'm going to remove the record pointing James Morse as an APEI reviewer from MAINTAINERS, as he doesn't even react to responses to patches sent by himself.
