Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: [RFC PATCH] Bluetooth: hci_sock: Set flag to all sockets
From:   Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <20211001035931.50485-1-hj.tedd.an@gmail.com>
Date:   Fri, 1 Oct 2021 07:43:40 +0200
Cc:     linux-bluetooth@vger.kernel.org,
        Tedd Ho-Jeong An <tedd.an@intel.com>
Content-Transfer-Encoding: 8BIT
Message-Id: <E6D38153-42EC-4AE2-9292-9EFE7F61318B@holtmann.org>
References: <20211001035931.50485-1-hj.tedd.an@gmail.com>
To:     Tedd Ho-Jeong An <hj.tedd.an@gmail.com>
Precedence: bulk

Hi Tedd,

> The mgmt_limited_event() send the event to the socket that matches the
> flag type, but also it skips to the given socket object in the
> parameter.
> 
> For Local Out of Band Data Updated Event and Experimental Feature
> Changed Event, it sets flags only for the socket which the change was
> triggered, the event cannot be sent to the client via any sockets
> because the flag is not set for other sockets and it doens't send to the
> socket which the change was triggered.
> 
> This patch adds the function that sets the flag for all available
> management sockets, so the mgmt_limited_event() still can send the event
> to the management sockets other than the one through which the change
> was triggered.

actually that is on purpose. Only the socket that used a specific mgmt commands gets to see the new events. So if you have a second listening socket that just cares about the events, it has to at least issue the “read” command to tell mgmt that it does understand it. There is no point in sending out signals to all mgmt sockets if you haven’t read an initial status first. The updates would make no sense to you.

Regards

Marcel