On Thu, Feb 13, 2025 at 8:10 PM Greg KH [off-list ref] wrote:

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Thu, Feb 13, 2025 at 07:57:15PM +0800, Hsin-chen Chuang wrote:

quoted

The btusb driver data is allocated by devm_kzalloc and is
automatically freed on driver detach, so I guess we don't have
anything to do here.

What?  A struct device should NEVER be allocated with devm_kzalloc.
That's just not going to work at all.

Noted. Perhaps that needs to be refactored together.

quoted

Or perhaps we should move btusb_disconnect's content here? Luiz, what
do you think?

I think something is really wrong here.  Why are you adding a new struct
device to the system?  What requires that?  What is this new device
going to be used for?

The new device is only for exposing a new sysfs attribute.

So originally we had a device called hci_dev, indicating the
implementation of the Bluetooth HCI layer. hci_dev is directly the
child of the usb_interface (the Bluetooth chip connected through USB).
Now I would like to add an attribute for something that's not defined
in the HCI layer, but lower layer only in Bluetooth USB.
Thus we want to rephrase the structure: usb_interface -> btusb (new
device) -> hci_dev, and then we could place the new attribute in the
new device.

Basically I kept the memory management in btusb unchanged in this
patch, as the new device is only used for a new attribute.
Would you suggest we revise the memory management since we added a
device in this module?

confused,


greg k-h

-- 
Best Regards,
Hsin-chen