On 28.08.2023 21:43, Henrik Grimler wrote: > Hi Konrad, > > On Sat, Aug 26, 2023 at 02:09:38PM +0200, Konrad Dybcio wrote: >> On 22.08.2023 17:01, Raymond Hackley wrote: >>> Hi Konrad, >>> >>>> What about the other subdevices registered with the RT5033 MFD? >>> >>> Currently the MFD is not able to control the flash LED, due to missing >>> driver for it. >>> Alternatively we control it with GPIO pins. With driver leds-sgm3140, the >>> binding is not under the RT5033 MFD. >> Hm.. I have mixed feelings.. >> >> Does the led controlled onboard this chip have some super complex >> functionality that is going to be exposed through a specific driver >> and that is not exposed through the sgm3140 driver? > > The rt5033-led&sgm3140 situation was discussed in msm8916-mainline > matrix room before, here is a summary for list. > > Using the full rt5033-led driver (old patchset here [1]) has some > benefits, like: > * led can have different intensity levels > * led can (supposedly) be used in strobe mode > > Using sgm3140 driver mostly works fine, but there could potentially be > situations where led stops working and a reboot to stock android > kernel is required to get it working again. So far that has only been > reproduced by first booting a kernel with full rt5033-led driver > (based on [1]), and then booting a kernel using sgm3140 driver > instead. > > [1] https://lore.kernel.org/linux-leds/1448446948-13729-1-git-send-email-ingi2.kim@xxxxxxxxxxx/ 2015, whoops.. Looks like the reviewers were mostly happy (style comments for the most part), so perhaps it'd be worth to bring it back? As for this patch, I'll be happy to take it if you can confirm the rt5033-leds driver won't require bindings changes (i.e. the node you're adding today would work fine as-is if you removed sgm3140 and probed the separate driver), at least in the form that it was posted in the link above.. Konrad
