On 16.03.19 04:26, Greg KH wrote: > No, it's just that those systems do not allow those devices to be > removed because they are probably not on a removable bus. Ok, devices (hw) might not be removable - that also the case for uarts builtin some SoCs, or the good old PC w/ 8250. But does that also mean that the driver should not be removable ? IMHO, even if that's the case, it's still inconsistent. The driver then shouldn't support a remove at all (or even builtin only), not just incomplete remove. >> Okay, I was on a wrong track here - I had the silly idea that it would >> make things easier if we'd do it the same way everywhere. > > "Consistent" is good, and valid, but touching old drivers that have few > users is always risky, and you need a solid reason to do so. Understood. By the way: do we have some people who have those old hw and could test? Should we (try to) create some ? Perhaps some "tester" entry in MAINTAINERS file ? (I could ask around several people who might have lots of old / rare hardware.) >> Understood. Assuming I've found some of these cases, shall I use devm >> oder just add the missing release ? > > If it actually makes the code "simpler" or "more obvious", sure, that's > fine. But churn for churns sake is not ok. Ok. > I put the review of new patch submissions on hold, yes. Almost all > maintainers do that as we can not add new patches to our trees at that > point in time. hmm, looks like a pipeline stall ;-) why not collecting in a separate branch, which later gets rebased to mainline when rc is out ? > And I do have other things I do during that period so it's not like I'm > just sitting around doing nothing :) So it's also a fixed schedule for your other work. Understood. It seems that this workflow can confuse people. Few days ago, somebody became nervous about missing reactions on patches. Your autoresponder worked for me, but maybe not for everybody. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
