On Wed, Aug 24, 2022 at 12:19 PM Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > >> I don't know if this is enough to make a dedicated TLC5925 driver > > >> desirable in the kernel. > > > I don't think you have enough justification for a new driver. One thing to keep in mind is that LEDs are MMI (man-machine-interface) and designed as such, so small glitches etc are fine as long as they are not noticeable by human perception... > After this message I first must withdraw my Rb tag, and turn my voice > against this driver because of the above. On the contrary we might ask > the GPIO library for a specific API to have what you do with the > user's consent of side effects. Linus, Bart, I'm talking of the > delayed (async) version of gpio_set_multiple(). But personally I think > it's not so easy to implement in a bugless manner (because we need to > synchronize it forcibly at any time we call another GPIO API against > the same chip). I suppose this can just be a gpio-led using the GPIO driver underneath? If the usecase for TLC5925 is such that it is often (as defined by experienced developers having seen it on boards in the wild) used as a GPIO expander rather than a pure LED driver, then it is better to have this in the GPIO subsystem in some or other form. If it is always just used for LEDs then my first comment about this being MMI applies I suppose. Or rather, ask the question from an operator point of view rather than a logic level point of view. (I think that was Andy's point though.) I agree that we probably need some generic library to properly handle the jungle of funny TTL-type constructs that is popping up left and right for GPIO. Someone should ideally sit down and think about what is common among these. Yours, Linus Walleij
