Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-3661-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 17 Apr 2024 10:32:55 +0200
From: Johan Hovold <johan@kernel.org>
To: quic_zijuhu <quic_zijuhu@quicinc.com>
Cc: luiz.dentz@gmail.com, marcel@holtmann.org,
	linux-bluetooth@vger.kernel.org, johan+linaro@kernel.org
Subject: Re: [PATCH] Bluetooth: qca: Fix nullptr dereference for non-serdev
 devices
Message-ID: <Zh-JNzlskY6ZvsSm@hovoldconsulting.com>
References: <1713325792-17181-1-git-send-email-quic_zijuhu@quicinc.com>
 <Zh9saGbOl-fXP6SD@hovoldconsulting.com>
 <5e4e62c8-d17f-45fd-9212-088eb026dc7b@quicinc.com>
 <Zh91zq13nZvH3-Yj@hovoldconsulting.com>
 <4dac0caa-629d-4b4d-ad54-f6ab15268524@quicinc.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4dac0caa-629d-4b4d-ad54-f6ab15268524@quicinc.com>

Again, make sure wrap you replies at 72 cols and trim unnecessary
context:

  https://docs.kernel.org/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions

On Wed, Apr 17, 2024 at 03:32:51PM +0800, quic_zijuhu wrote:
> On 4/17/2024 3:10 PM, Johan Hovold wrote:
> > On Wed, Apr 17, 2024 at 02:51:38PM +0800, quic_zijuhu wrote:

> >> i have submitted below patches to add supports for all other
> >> non-serdev controllers.
> > 
> >> https://patchwork.kernel.org/project/bluetooth/list/?series=844120
> > 
> > Ok, you need it for some future changes, but I'm afraid that adding new
> > random vendor specific ioctls like you do in that is series is a no-go.

> it is a generic ioctl, for QCA, it is used to specific soc_type. it
> maybe be used by other vendor driver to set user specified info.

In it's current form it's a vendor specific hack that is never going to
make it upstream.

For a start, you don't even make sure that the types becomes part of the
ABI, which means that passing, say, type 5 can mean different things
depending on the kernel version.

Can't you just retrieve the device type from the device itself? If it's
already powered, you should not need to know this beforehand.
  
Johan