Re: [PATCH v6 1/2] Bluetooth: qca: Fix BT enable failure for QCA6390

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
Luiz Augusto von Dentz





[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux