Re: [Patch v1] Bluetooth: Add Rfkill driver for Intel Bluetooth controller

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: chethantn@gmail.com, chethan.tumkur.narayan@intel.com,
	linux-bluetooth@vger.kernel.org, amit.k.bag@intel.com,
	raghuram.hegde@intel.com, sukumar.ghorai@intel.com,
	rajatja@chromium.org
Subject: Re: [Patch v1] Bluetooth: Add Rfkill driver for Intel Bluetooth controller
Date: Wed, 7 Nov 2018 10:40:36 -0800	[thread overview]
Message-ID: <CAKdAkRTfBV67=KGmimsc6obeHcjgo63UpG=Jn+C=NFDQ2cNE=A@mail.gmail.com> (raw)
In-Reply-To: <CD6DE466-5E73-473C-8943-684FBAEF337E@holtmann.org>

On Tue, Nov 6, 2018 at 11:28 PM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Dmitry,
>
> >> We are planning to further implement the followings, kindly please
> >> provide your suggestions.
> >> 1. To handle more than 1 Intel BT controller connected to platform,
> >> will keep list of the objects in "static const struct acpi_device_id
> >> intel_bt_rfkill_acpi_match[] ". And keep a list of "struct
> >> intel_bt_rfkill_dev" for each of the acpi object.
> >> 2.  With this implementation from user space RF kill for the device
> >> object is achieved, however need to map the rfkill object with the
> >> corresponding "hdev" so that on error from the controller kernel can
> >> do the reset through this RF Kill driver.
> >
> > I am confused, why you model a generic chip reset functionality via
> > RFKill subsystem. As far as I understand, the issue is that you want to
> > be able to reset the chip when it gets confused and not actually disable
> > the chip/stop it from emitting RF signals.
> >
> > I believe this functionality should be contained in the driver and you
> > simply need to come with a way to tie the adapter instance with data in
> > ACPI, probably based on physical USB connection.
>
> it is impossible to do that in the driver since what the GPIO is doing is to push the USB device off the bus. So you actually see an USB disconnect and a new re-enumeration when it comes back. Meaning the driver knows nothing during that time.

The driver would know that it is in the middle of resetting the
device. The fact that the device disappears from the bus is not a big
deal. You just need to make sure you finish the reset task running
before finishing teardown of the device in disconnect method.

> This is a classic soft RFKILL switch like we have seen in the early Thinkpads.

It is not RFkill as, as far as I understand, it does not guarantee
that it actually blocks the transmitter. It really is a reset line and
its purpose is to unwedge the chip, not keep it in the off state. I do
not think there is a reason to export this as RFkill switch to
userspace and then build infrastructure to recognize that this is
special kind of RFkill switch that can be used to work around issues
in the controller. Have the driver assert and deassert it to kick
itself off the bus, the USB hotplug will take care of the rest.

Thanks.

-- 
Dmitry