On 4/24/2024 10:41 PM, Bartosz Golaszewski wrote: > On Wed, 24 Apr 2024 at 16:25, quic_zijuhu <quic_zijuhu@xxxxxxxxxxx> wrote: >> >> On 4/24/2024 10:19 PM, Bartosz Golaszewski wrote: >>> On Wed, 24 Apr 2024 at 16:08, Luiz Augusto von Dentz >>> <luiz.dentz@xxxxxxxxx> wrote: >>>> >>>> Hi Bartosz, >>>> >>>> On Wed, Apr 24, 2024 at 10:00 AM Bartosz Golaszewski >>>> <bartosz.golaszewski@xxxxxxxxxx> wrote: >>>>> >>>>> On Wed, 24 Apr 2024 at 15:53, quic_zijuhu <quic_zijuhu@xxxxxxxxxxx> wrote: >>>>>> >>>>>>>>> >>>>>>>>> Please slow down here. Zijun's patch works and Bartosz's patch does not. >>>>>>>>> I don't think Zijun means any ill intent. I am replying to Bartosz's >>>>>>>>> patch right now. >>>>>>>> >>>>>>>> Ok, that is great feedback, so I might be picking up the Zijun v7 set >>>>>>>> if we don't find any major problems with it. >>>>>>>> >>>>>>> >>>>>>> Luiz, >>>>>>> >>>>>>> Please consider my alternative[1] also tested by Wren. Zijun's usage >>>>>>> of GPIO API is wrong. >>>>>>> >>>>>> why is it wrong ? >>>>>> >>>>> >>>>> I have already told you that at least three times. But whatever, let >>>>> me repeat again: gpiod_get_optional() returns NULL if the given GPIO >>>>> is not assigned to the device in question OR a pointer to a valid GPIO >>>>> descriptor. Anything else returned by it is an error and the driver >>>>> must abort probe(). >>>> >>>> Ok, but there are other fixes on top of it: >>>> >>>> https://patchwork.kernel.org/project/bluetooth/patch/1713932807-19619-3-git-send-email-quic_zijuhu@xxxxxxxxxxx/ >>>> >>>> I guess that could go in but it would really help if you guys could >>>> work together so we don't have more competing solutions. >>>> >>> >>> These threads with their 7 patch versions from Zijun within 2 days or >>> so have become very chaotic. Let me summarize: there are two >>> regressions: one caused by my commit 6845667146a2 ("Bluetooth: >>> hci_qca: Fix NULL vs IS_ERR_OR_NULL check in qca_serdev_probe") and a >>> second caused by Krzysztof's commit 272970be3dab ("Bluetooth: hci_qca: >>> Fix driver shutdown on closed serdev"). The patch I linked here is how >>> I propose to fix my regression only. These fixes don't seem to >>> conflict with one another. >>> >> it is not conflict issue, from my perspective, you fix are wrong. >> do you see my patch change log? >> >>> We (Krzysztof and I) have provided feedback to Zijun but he refused to >>> address it and instead kept on resending his patches every couple >>> hours. Zijun's patch 1/2 proposed to revert my commit 6845667146a2. I >>> disagreed and proposed a way forward by fixing the regression. This >>> fix was incorrect as pointed out by Wren, so I submitted v2 which >>> works. >>> >> v2 is not right from my point as i commented with your solution. >> >> you don't answer my questions commented within your solution. >> >> what is your question i don't answer? >> >>> Bartosz >> > > Luiz, > > This is an example of how Zijun will borrow any attempt at meaningful > communication under a heap of incomprehensible emails. Krzysztof has > already given up and I think I will stop too now. As the GPIO > maintainer I suggest you take my fix for this regression. I can't make > you though and I've already wasted way too much time on it. Your call. > how about GPIO maintainer? it is your change about GPIOs causes serious regression issue. i maybe send many mails. but dos it have any relevant my change's rightness. do you find anything my change have wrong usage about GPIO about the case i care about? > Bartosz
