Dmitry Baryshkov <[email protected]> 于2026年6月25日周四 22:57写道： > > On Thu, Jun 25, 2026 at 09:26:47PM +0800, Sunyun Yang wrote: > > Krzysztof Kozlowski <[email protected]> 于2026年6月25日周四 21:17写道： > > > > > > On 25/06/2026 15:14, Sunyun Yang wrote: > > > > Krzysztof Kozlowski <[email protected]> 于2026年6月25日周四 20:54写道： > > > >> > > > >> On 08/05/2026 15:40, [email protected] wrote: > > > >>> + > > > >>> +static void lt9611c_reset(struct lt9611c *lt9611c) > > > >>> +{ > > > >>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1); > > > >>> + msleep(20); > > > >>> + > > > >>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 0); > > > >>> + msleep(20); > > > >>> + > > > >>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1); > > > >> > > > >> This is just plain wrong. Why do you assert, then de-assert and then > > > >> finally assert AGAIN the reset leaving the device in powerdown stage? > > > >> > > > > I am using software to emulate the hardware RESET button on our EVB. > > > > When the hardware RESET button is pressed while our chip is running, > > > > the signal level changes from HIGH to LOW and then back to HIGH. > > > > > > > > Of course, we can also use the following: > > > > static void lt9611c_reset(struct lt9611c *lt9611c) > > > > { > > > > gpiod_set_value_cansleep(lt9611c->reset_gpio, 0); > > > > msleep(50); > > > > gpiod_set_value_cansleep(lt9611c->reset_gpio, 1); > > > > msleep(20); > > > > } > > > > > > Makes no sense either and you just did not get the point and did not > > > answer my question. I asked WHY you leave asserted. Answer "we emulate" > > > is just plain wrong. > > > > > > So again please answer: > > > > > > Why do you leave device with reset asserted? > > > > > > > devicetree: reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>; > > It should be GPIO_ACTIVE_LOW, if the pin as active-low. >
Yes, I understand that. I used GPIO_ACTIVE_HIGH intentionally, because I did not want to modify the existing reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH> property in the lontium-lt9611.yaml device tree file that was submitted by others. If I used GPIO_ACTIVE_LOW, I would have to change that line in the device tree binding, and also update the driver files lontium-lt9611.c and lontium-lt9611uxc.c accordingly. That would add a significant amount of extra work for me. Moreover, in much earlier versions, I had added a separate lontium-lt9611c.yaml file to decouple this new chip from the existing lontium-lt9611 / lontium-lt9611uxc support. However, Dmitry Baryshkov considered that unnecessary and asked me to merge lontium-lt9611c together with the existing drivers. He also told me that the differences in reset‑pin and VDD/VCC supply did not matter. The existing device tree and driver code already had issues, and I had raised them with you before. At that time, you did not seem to care, and the community reviewers insisted that I must follow your directions. So I did exactly what you told me to do. > > > > GPIO_ACTIVE_HIGH: > > > > gpiod_set_value_cansleep(lt9611c->reset_gpio, 0); ------ reset pin > > is Low level : Clear the register configuration in the chip to stop > > the chip from working. > > > > gpiod_set_value_cansleep(lt9611c->reset_gpio, 1); ------ reset pin > > is high level: The chip resumes operation. > > > > > > > > > Best regards, > > > Krzysztof > > -- > With best wishes > Dmitry
