On Tue, 22 Sep 2020 18:38:42 +0200 Pavel Machek <pavel@xxxxxx> wrote: > On Sun 2020-09-20 23:54:36, Marek Behun wrote: > > On Sun, 20 Sep 2020 23:45:32 +0200 > > Pavel Machek <pavel@xxxxxx> wrote: > > > > > Hi! > > > > > > > Now that the potential use-after-free issue is resolved we can use > > > > devres for LED registration in this driver. > > > > > > > > By using devres version of LED registering function we can remove the > > > > .remove method from this driver. > > > > > > > > Signed-off-by: Marek Behún <marek.behun@xxxxxx> > > > > Cc: Dan Murphy <dmurphy@xxxxxx> > > > > > > AFAICT this one is buggy, I sent explanation before. Why are you > > > resubmitting it? > > > > The previous patch in this series (v3 5/9) should solve this issue and > > th commit message explains how. > > Aha, let me see. > > Will 5/9 have some side-effects, like device appearing at different > place in sysfs? Yes, unfortunately. Before this path the led should be in /sys/devices/.../i2c-client/leds/led or somthing like that, and after /sys/devices/..c/i2c-client/mfd/leds/led But it should have been this way from beginning, I think. The other driver, regulator, registers its device under the mfd device. The question is whether this will break something for someone. I don't think so, but... > > First few patches look ok, but it would be really nice someone tested > complete sereies. > > Best regards, > Pavel
