public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hedberg <johan.hedberg@gmail.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
	Rob Herring <robh+dt@kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	"open list:BLUETOOTH DRIVERS" <linux-bluetooth@vger.kernel.org>,
	linux-serial@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
	"Gustavo F. Padovan" <gustavo@padovan.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>, Johan Hovold <johan@kernel.org>,
	linux-sunxi@googlegroups.com, linux-amlogic@lists.infradead.org,
	Larry.Finger@lwfinger.net
Subject: Re: [RFC v1 7/8] Bluetooth: hci_serdev: remove the HCI_UART_INIT_PENDING check
Date: Sun, 19 Nov 2017 22:43:25 +0200	[thread overview]
Message-ID: <20171119204325.GA24345@x1c.home> (raw)
In-Reply-To: <CAFBinCC_G845v4cZW9hvwYEDQhTCLW1iG_JWzAz9Gu42rM4_Zg@mail.gmail.com>

Hi Martin,

On Sun, Nov 19, 2017, Martin Blumenstingl wrote:
> >> @@ -333,9 +333,6 @@ int hci_uart_register_device(struct hci_uart *hu,
> >>       else
> >>               hdev->dev_type = HCI_PRIMARY;
> >>
> >> -     if (test_bit(HCI_UART_INIT_PENDING, &hu->hdev_flags))
> >> -             return 0;
> >> -
> >
> > then lets also remove the flag definition itself. Or if that is
> > still needed for some legacy operation, then describe this. For
> > example I also see it used in hci_serdev.c and main question would
> > be if it is used there as well or some legacy cruft.
> 
> this flag is still used in hci_ldisc.c (if that's what you mean
> instead of hci_serdev.c):
> as far as I understand the code it's used to postpone the
> hci_register_dev() call until the sync response is received
> 
> Johan Hedberg added this code in 9f2aee848fe6 ("Bluetooth: Add delayed
> init sequence support for UART controllers") - it would be great if he
> could comment on this (he is CC'ed on this mail)

That patch is over five years old, so don't count on me remembering the
details ;)  That said, your analysis of its use sounds correct. It's
possible however that we've since then given HCI drivers other
capabilities that would make the INIT_PENDING flag redundant. E.g. the
setup callback didn't exist at the time that I wrote the patch.

Johan

  reply	other threads:[~2017-11-19 20:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 22:35 [RFC v1 0/8] Realtek Bluetooth serdev support (H5 protocol) Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 1/8] serdev: implement parity configuration Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 2/8] Bluetooth: btrtl: add MODULE_FIRMWARE declarations Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 3/8] Bluetooth: btrtl: split the device initialization into smaller parts Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 4/8] Bluetooth: btrtl: add support for retrieving the UART settings Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 5/8] Bluetooth: btrtl: add support for the RTL8723BS and RTL8723DS chips Martin Blumenstingl
2017-11-19  8:25   ` Marcel Holtmann
2017-11-19 20:38     ` Martin Blumenstingl
2017-11-19 21:17       ` Marcel Holtmann
2017-11-26 22:23         ` Martin Blumenstingl
2017-11-26 22:47           ` Emil Lenngren
2017-11-27 10:00           ` Marcel Holtmann
2017-11-17 22:35 ` [RFC v1 6/8] Bluetooth: hci_h5: add support for Realtek UART Bluetooth modules Martin Blumenstingl
2017-11-19  8:29   ` Marcel Holtmann
2017-11-19 20:28     ` Martin Blumenstingl
2018-03-16 22:22   ` Marcel Holtmann
2018-03-17 22:50     ` Jeremy Cline
2018-03-18 10:46       ` Marcel Holtmann
2018-03-18 22:52       ` Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 7/8] Bluetooth: hci_serdev: remove the HCI_UART_INIT_PENDING check Martin Blumenstingl
2017-11-19  8:21   ` Marcel Holtmann
2017-11-19 20:24     ` Martin Blumenstingl
2017-11-19 20:43       ` Johan Hedberg [this message]
2017-11-17 22:35 ` [RFC v1 8/8] dt-bindings: net: bluetooth: add support for Realtek Bluetooth chips Martin Blumenstingl
2017-11-20 21:09   ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171119204325.GA24345@x1c.home \
    --to=johan.hedberg@gmail.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavo@padovan.org \
    --cc=johan@kernel.org \
    --cc=jslaby@suse.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=marcel@holtmann.org \
    --cc=mark.rutland@arm.com \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox