On 4/24/2024 11:31 PM, Luiz Augusto von Dentz wrote: > Hi Quic_zijuhu, > > On Wed, Apr 24, 2024 at 10:46 AM quic_zijuhu <quic_zijuhu@xxxxxxxxxxx> wrote: >> >> 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. > > Well you are not making it any better if you are still claiming the > maintainer doesn't know what doing when you should really be thanking > him for looking into this, now perhaps his changes doesn't address a > particular problem you are trying to solve nevertheless it is worth > incorporating his changes in your set and then have yours on top > without reverting his changes? Can you do that or there is something > fundamentally broken with that. > > Everyone here probably have their own assignments, so you are getting > sort of _free_ consultancy, so please instead continue disputing what > we are suggesting at least try to incorporate the suggested changes, > we want to have it fixed properly so we don't have to keep receiving > the same changes over and over again which is a waste of everyone's > time, including yours. > sorry for my offense. suggest merge my change.
