All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: "\"Mark-YW Chen (陳揚文)\"" <Mark-YW.Chen@mediatek.com>
Cc: "Johan Hedberg" <johan.hedberg@gmail.com>,
	linux-bluetooth <linux-bluetooth@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Sean Wang" <Sean.Wang@mediatek.com>,
	"\"Peter Tsao (曹珆彰)\"" <Peter.Tsao@mediatek.com>
Subject: Re: [PATCH 1/1] [Add support Mediatek mt7921U]
Date: Sat, 26 Dec 2020 21:17:24 +0100	[thread overview]
Message-ID: <5925338F-C8E3-4FDE-9477-256EC2363C49@holtmann.org> (raw)
In-Reply-To: <292c69c1038242d5b0d03fb7b4675555@mtkmbs08n1.mediatek.inc>

Hi Mark,

> Thanks for your suggestions, I will remove the duplicate definitions and functions.
> 
> Firstly, we will add the support of enabling MT7921U in btusb.c
> Secondary, we will discuss the driver architecture with you.
> Finally, we update the common part and hif part for MT7921.
> 
> I have a couple questions for driver architecture.
> 1. Global dev.
> 2. Unify common part.
> 3. HIF part (usb/sdio/pcie/uart)
>> 
>>> This patch adds the support of enabling MT7921U, it's USB-based
>>> Bluetooth function.
>>> 
>>> There are some component in the Mediatek driver.
>>> 1. Btmtk_main: it's common code for Mediatek devices,
>>>  such as firmware download, chip initialization,
>>>  state machine handling and etc.
>>> 2. Btmtkusb: it's for usb interface,
>>>  such as usb endpoint enumeration, urb handling and etc.
>>> 
>>> Firstly, we update the common part and usb part for MT7921U.
>>> Secondly, we will add the support MT7921S, it's SDIO-based device.
>>> Finally, we will add the procedure to support uart/pcie interfaces.
>> 
>> create a btmtk.[ch] module like the other vendors did if it makes sense.
>> Otherwise just skip that part for now and get btmtkusb.c driver working. You
>> can later unify between all 3 transports.
>> 
>> I would do the latter since it would first make sense to really see where the
>> common parts are. And I have to be frank, this driver needs massive cleanup. I
>> am not going to accept this tons of copy-and-paste left and right.
>> 
>> Please provide the content of /sys/kernel/debug/usb/devices in the commit
>> message.
>> 
>>> +/* To support dynamic mount of interface can be probed */
>>> +static int btmtk_intf_num = BT_MCU_MINIMUM_INTERFACE_NUM;
>>> +/* To allow g_bdev being sized from btmtk_intf_num setting */
>>> +static struct btmtk_dev **g_bdev;
>> 
>> NO. Period. No global dev instances.
> 
> [Global dev.]
> The global dev is for our state machine that design for error recovery, such as chip reset, memory dump and etc.
> We must to make sure state machine transition that is the same flow for each interfaces (usb/sdio/pcie/uart).
> [Mediatek driver]
> -> Create a dev before interface probe.
> [Linux kernel Bluetooth driver]
> -> Create a dev in interface probe (btusb_probe).
> 
> May we create a global dev before interface probe?

No. Please design things properly. Non of the drivers have global devices.

>>> +
>>> +/**
>>> + * Kernel Module init/exit Functions
>>> + */
>>> +static int __init main_driver_init(void)
>>> +{
>>> +	int ret = 0;
>>> +	int i;
>>> +
>>> +	/* Mediatek Driver Version */
>>> +	BTMTK_INFO("%s: MTK BT Driver Version : %s", __func__, VERSION);
>>> +
>>> +	ret = main_init();
>>> +	if (ret < 0)
>>> +		return ret;
>>> +
>>> +	for (i = 0; i < btmtk_intf_num; i++)
>>> +		btmtk_set_chip_state(g_bdev[i], BTMTK_STATE_DISCONNECT);
>>> +
>>> +	ret = btmtk_cif_register();
>>> +	if (ret < 0) {
>>> +		BTMTK_ERR("*** USB registration failed(%d)! ***", ret);
>>> +		main_exit();
>>> +		return ret;
>>> +	}
>>> +
>>> +	BTMTK_INFO("%s: Done", __func__);
>>> +	return ret;
>>> +}
>> 
>> NO. Period. Use module_usb_driver() and if you need anything more, you are
>> doing something wrong.
> 
> We would like to unify state machine, dev allocate, hif_hook and hif_register.
> [Unify Common Part]: btmtk_main
> State machine: Mediatek chip error recovery
> Dev allocate: Bluetooth dev.
> Mediatek chip-related behavior: Firmware download.
> HCI device-related: hci register, open, close and send_frame.
> 
> [HIF Part] : btmtkusb/btmtksdio/btmtkuart
> hif_hook (cif interface): read/write register, open/close, chip reset and etc.
> hif_register (cif register): hif registration-related, such as usb_register/sdio_register_driver.
> 
> May we use the driver architecture?

You can do that, but then first start with the existing btmtksdio and btmtkuart drivers to show me how you want to design it. You still have to design it cleanly.

Regards

Marcel


WARNING: multiple messages have this Message-ID (diff)
From: Marcel Holtmann <marcel@holtmann.org>
To: "\"Mark-YW Chen (陳揚文)\"" <Mark-YW.Chen@mediatek.com>
Cc: "Johan Hedberg" <johan.hedberg@gmail.com>,
	"Sean Wang" <Sean.Wang@mediatek.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-bluetooth <linux-bluetooth@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"\"Peter Tsao (曹珆彰)\"" <Peter.Tsao@mediatek.com>
Subject: Re: [PATCH 1/1] [Add support Mediatek mt7921U]
Date: Sat, 26 Dec 2020 21:17:24 +0100	[thread overview]
Message-ID: <5925338F-C8E3-4FDE-9477-256EC2363C49@holtmann.org> (raw)
In-Reply-To: <292c69c1038242d5b0d03fb7b4675555@mtkmbs08n1.mediatek.inc>

Hi Mark,

> Thanks for your suggestions, I will remove the duplicate definitions and functions.
> 
> Firstly, we will add the support of enabling MT7921U in btusb.c
> Secondary, we will discuss the driver architecture with you.
> Finally, we update the common part and hif part for MT7921.
> 
> I have a couple questions for driver architecture.
> 1. Global dev.
> 2. Unify common part.
> 3. HIF part (usb/sdio/pcie/uart)
>> 
>>> This patch adds the support of enabling MT7921U, it's USB-based
>>> Bluetooth function.
>>> 
>>> There are some component in the Mediatek driver.
>>> 1. Btmtk_main: it's common code for Mediatek devices,
>>>  such as firmware download, chip initialization,
>>>  state machine handling and etc.
>>> 2. Btmtkusb: it's for usb interface,
>>>  such as usb endpoint enumeration, urb handling and etc.
>>> 
>>> Firstly, we update the common part and usb part for MT7921U.
>>> Secondly, we will add the support MT7921S, it's SDIO-based device.
>>> Finally, we will add the procedure to support uart/pcie interfaces.
>> 
>> create a btmtk.[ch] module like the other vendors did if it makes sense.
>> Otherwise just skip that part for now and get btmtkusb.c driver working. You
>> can later unify between all 3 transports.
>> 
>> I would do the latter since it would first make sense to really see where the
>> common parts are. And I have to be frank, this driver needs massive cleanup. I
>> am not going to accept this tons of copy-and-paste left and right.
>> 
>> Please provide the content of /sys/kernel/debug/usb/devices in the commit
>> message.
>> 
>>> +/* To support dynamic mount of interface can be probed */
>>> +static int btmtk_intf_num = BT_MCU_MINIMUM_INTERFACE_NUM;
>>> +/* To allow g_bdev being sized from btmtk_intf_num setting */
>>> +static struct btmtk_dev **g_bdev;
>> 
>> NO. Period. No global dev instances.
> 
> [Global dev.]
> The global dev is for our state machine that design for error recovery, such as chip reset, memory dump and etc.
> We must to make sure state machine transition that is the same flow for each interfaces (usb/sdio/pcie/uart).
> [Mediatek driver]
> -> Create a dev before interface probe.
> [Linux kernel Bluetooth driver]
> -> Create a dev in interface probe (btusb_probe).
> 
> May we create a global dev before interface probe?

No. Please design things properly. Non of the drivers have global devices.

>>> +
>>> +/**
>>> + * Kernel Module init/exit Functions
>>> + */
>>> +static int __init main_driver_init(void)
>>> +{
>>> +	int ret = 0;
>>> +	int i;
>>> +
>>> +	/* Mediatek Driver Version */
>>> +	BTMTK_INFO("%s: MTK BT Driver Version : %s", __func__, VERSION);
>>> +
>>> +	ret = main_init();
>>> +	if (ret < 0)
>>> +		return ret;
>>> +
>>> +	for (i = 0; i < btmtk_intf_num; i++)
>>> +		btmtk_set_chip_state(g_bdev[i], BTMTK_STATE_DISCONNECT);
>>> +
>>> +	ret = btmtk_cif_register();
>>> +	if (ret < 0) {
>>> +		BTMTK_ERR("*** USB registration failed(%d)! ***", ret);
>>> +		main_exit();
>>> +		return ret;
>>> +	}
>>> +
>>> +	BTMTK_INFO("%s: Done", __func__);
>>> +	return ret;
>>> +}
>> 
>> NO. Period. Use module_usb_driver() and if you need anything more, you are
>> doing something wrong.
> 
> We would like to unify state machine, dev allocate, hif_hook and hif_register.
> [Unify Common Part]: btmtk_main
> State machine: Mediatek chip error recovery
> Dev allocate: Bluetooth dev.
> Mediatek chip-related behavior: Firmware download.
> HCI device-related: hci register, open, close and send_frame.
> 
> [HIF Part] : btmtkusb/btmtksdio/btmtkuart
> hif_hook (cif interface): read/write register, open/close, chip reset and etc.
> hif_register (cif register): hif registration-related, such as usb_register/sdio_register_driver.
> 
> May we use the driver architecture?

You can do that, but then first start with the existing btmtksdio and btmtkuart drivers to show me how you want to design it. You still have to design it cleanly.

Regards

Marcel


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

  reply	other threads:[~2020-12-26 20:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-22 15:05 [PATCH 1/1] [Add support Mediatek mt7921U] Mark-YW.Chen
2020-12-22 21:36 ` Marcel Holtmann
2020-12-25  8:35   ` Mark-YW Chen (陳揚文)
2020-12-26 20:17     ` Marcel Holtmann [this message]
2020-12-26 20:17       ` Marcel Holtmann
2021-01-18 16:29 mark-yw.chen

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=5925338F-C8E3-4FDE-9477-256EC2363C49@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=Mark-YW.Chen@mediatek.com \
    --cc=Peter.Tsao@mediatek.com \
    --cc=Sean.Wang@mediatek.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.