Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221029202454.25651-1-swyterzone@gmail.com> <20221029202454.25651-3-swyterzone@gmail.com>
 <CABBYNZKnw+b+KE2=M=gGV+rR_KBJLvrxRrtEc8x12W6PY=LKMw@mail.gmail.com> <ac1d556f-fe51-1644-0e49-f7b8cf628969@gmail.com>
In-Reply-To: <ac1d556f-fe51-1644-0e49-f7b8cf628969@gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Wed, 9 Nov 2022 14:39:06 -0800
Message-ID: <CABBYNZJytVc8=A0_33EFRS_pMG6aUKnfFPsGii_2uKu7_zENtQ@mail.gmail.com>
Subject: Re: [PATCH 3/3] Bluetooth: btusb: Add a parameter to let users
 disable the fake CSR force-suspend hack
To:     Swyter <swyterzone@gmail.com>
Cc:     marcel@holtmann.org, johan.hedberg@gmail.com, davem@davemloft.net,
        edumazet@google.com, kuba@kernel.org, luiz.von.dentz@intel.com,
        quic_zijuhu@quicinc.com, hdegoede@redhat.com,
        linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
        netdev@vger.kernel.org, Jack <ostroffjh@users.sourceforge.net>,
        Paul Menzel <pmenzel@molgen.mpg.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Swyter,

On Wed, Nov 9, 2022 at 1:30 PM Swyter <swyterzone@gmail.com> wrote:
>
> On 09/11/2022 21:49, Luiz Augusto von Dentz wrote:
> > Hi Ismael,
> >
> > On Sat, Oct 29, 2022 at 1:25 PM Ismael Ferreras Morezuelas
> > <swyterzone@gmail.com> wrote:
> >>
> >> A few users have reported that their cloned Chinese dongle doesn't
> >> work well with the hack Hans de Goede added, that tries this
> >> off-on mechanism as a way to unfreeze them.
> >>
> >> It's still more than worthwhile to have it, as in the vast majority
> >> of cases it either completely brings dongles to life or just resets
> >> them harmlessly as it already happens during normal USB operation.
> >>
> >> This is nothing new and the controllers are expected to behave
> >> correctly. But yeah, go figure. :)
> >>
> >> For that unhappy minority we can easily handle this edge case by letti=
ng
> >> users disable it via our =C2=ABbtusb.disable_fake_csr_forcesuspend_hac=
k=3D1=C2=BB kernel option.
> >
> > Don't really like the idea of adding module parameter for device
> > specific problem.
>
> It's not for a single device, it's for a whole class of unnamed devices
> that are currently screwed even after all this.
>
>
> >> -               ret =3D pm_runtime_suspend(&data->udev->dev);
> >> -               if (ret >=3D 0)
> >> -                       msleep(200);
> >> -               else
> >> -                       bt_dev_warn(hdev, "CSR: Couldn't suspend the d=
evice for our Barrot 8041a02 receive-issue workaround");
> >> +                       ret =3D pm_runtime_suspend(&data->udev->dev);
> >> +                       if (ret >=3D 0)
> >> +                               msleep(200);
> >> +                       else
> >> +                               bt_dev_warn(hdev, "CSR: Couldn't suspe=
nd the device for our Barrot 8041a02 receive-issue workaround");
> >
> > Is this specific to Barrot 8041a02? Why don't we add a quirk then?
> >
>
> We don't know how specific it is, we suspect the getting stuck thing happ=
ens with Barrot controllers,
> but in this world of lasered-out counterfeit chip IDs you can never be su=
re. Unless someone decaps them.
>
> Hans added that name because it's the closest thing we have, but this app=
lies to a lot of chips.
> So much that now we do the hack by default, for very good reasons.
>
> So please reconsider, this closes the gap.
>
> With this last patch we go from ~+90% to almost ~100%, as the rest of gen=
eric quirks we added
> don't really hurt; even if a particular dongle only needs a few of the zo=
o of quirks we set,
> it's alright if we vaccinate them against all of these, except some are "=
allergic"
> against this particular "vaccine". Let people skip this one. :-)
>
> You know how normal BT controllers are utterly and inconsistently broken,=
 now imagine you have a whole host
> of vendors reusing a VID/PID/version/subversion, masking as a CSR for biz=
arre reasons to avoid paying
> any USB-IF fees, or whatever. That's what we are fighting against here.

I see, but for suspend in particular, can't we actually handle it
somehow? I mean if we can detect the controller is getting stuck and
print some information and flip the quirk? Otherwise Im afraid this
parameter will end up always being set by distros to avoid suspend
problems.

--=20
Luiz Augusto von Dentz