Message-ID:
 <SYBP282MB35286B93C3FA936192CF270ABBD62@SYBP282MB3528.AUSP282.PROD.OUTLOOK.COM>
Date: Wed, 26 Jun 2024 19:37:56 +0800
From: Jinjian Song <songjinjian@...mail.com>
To: ryazanov.s.a@...il.com,
	Jinjian Song <songjinjian@...mail.com>,
	chandrashekar.devegowda@...el.com,
	chiranjeevi.rapolu@...ux.intel.com,
	haijun.liu@...iatek.com,
	m.chetan.kumar@...ux.intel.com,
	ricardo.martinez@...ux.intel.com,
	loic.poulain@...aro.org,
	johannes@...solutions.net,
	davem@...emloft.net,
	edumazet@...gle.com,
	kuba@...nel.org,
	pabeni@...hat.com
Cc: jinjian.song@...ocom.com,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [net-next v2 2/2] net: wwan: t7xx: Add debug port

On 25.06.2024 11:45, Jinjian Song wrote:
>> --- a/Documentation/networking/device_drivers/wwan/t7xx.rst
>> +++ b/Documentation/networking/device_drivers/wwan/t7xx.rst
>> @@ -56,6 +56,10 @@ Device mode:
>>   - ``fastboot_switching`` represents that device in fastboot switching status
>>   - ``fastboot_download`` represents that device in fastboot download status
>>   - ``fastboot_dump`` represents that device in fastboot dump status
>> +- ``debug`` represents switching on debug ports (write only)
>> +- ``normal`` represents switching off debug ports (write only)
>> +
>> +Currently supported debug ports (ADB/MIPC)
>
>Could you clarify a bit the availability of these debug ports (ADB and 
>MIPC)? Looks like these ports are always available when a modem is 
>booted in a 'normal' mode. They are available among other types of ports 
>like AT, MBIM, etc. And you want to hide them, or speaking more 
>precisely, you want to make debug ports availability configurable. Do I 
>understand it right?

Yes, your understanding is basically corret.
1. ADB port, When we want to pull/push some files from modem or run shell command
on modem, we usually use the adb command.
e.g., "pcie-adb shell", then commands we input will run in modem shell terminal, if
we input shell command like "ls,pwd" it feedback the result on modem side.
or "pcie-adb pull xxx.file" to get the xxx.file from modem file system.
So if we want to get some file(config or dump) from modem or change some file on 
modem, it will work.

MIPC port, When we optimize modem antenna tunner or noise profiling, we will use
this port to set parameters through this MTK diagnostic interface, the command
through this MIPC port defined by MTK.

2.All the port channel configuration is determined, so if modem open the port
channel, driver can communicate with modem. It means if modem configure 
AT/MBIM/ADB/MIPC channel open, then when modem booting up with them.
I want to hidden ADB and MIPC port, because the ports channel is off default
by modem. If needed when debugging, we can open them.

>I just have doubts regarding the chosen configuration approach. We 
>already have a 'ready' mode indicating a normal operation. Now we are 
>introducing a 'debug' mode that only makes available ADB/MIPC ports, but 
>reading from the 't7xx_mode' file will return 'ready'. And also we are 
>going to introduce a 'normal' mode, that actually means 'hide this debug 
>ports please'. While easy to introduce, looks like puzzle for a user.

Yes, it looks like puzzle for a user, 't7xx_mode' should be the running
state machine of modem, I want to express the port status by 'debug' and
'normal' of t7xx driver.

>I also would like to mention a potentially dangerous case. If a modem is 
>already booted in the 'fastboot_download' mode, and someone writes 
>'normal' into the 't7xx_mode' file. Will it switch the modem into a 
>normal operational state. Also the activation itself lacks a couple of 
>checks regarding a double port activation. Please see below.
>
>How we can make this configuration process less puzzling? Should we 
>rework the state machine more carefully or should we introduce a 
>dedicated control file this purpose?

'debug' and 'normal' only effect the ports which configurate the attribute,
'.debug = true', when modem in 'fastboot_download', user set 'normal', then
driver will find the ports proxy configuration which '.debug' is true and 
call the port->unint to release the port. 'fastboot_download' has no 
attribute '.debug = true', so no oprate will occured.

How about create a new sysfs node named 't7xx_port' to control the ports
state in t7xx driver? 'debug' or 'normal'.


>   
> @@ -100,7 +102,27 @@ static const struct t7xx_port_conf t7xx_port_conf[] = {
>   		.path_id = CLDMA_ID_AP,
>   		.ops = &ctl_port_ops,
>   		.name = "t7xx_ap_ctrl",
> -	},
> +	}, {
> +		.tx_ch = PORT_CH_AP_ADB_TX,
> +		.rx_ch = PORT_CH_AP_ADB_RX,
> +		.txq_index = Q_IDX_ADB,
> +		.rxq_index = Q_IDX_ADB,
> +		.path_id = CLDMA_ID_AP,
> +		.ops = &wwan_sub_port_ops,
> +		.name = "adb",
> +		.port_type = WWAN_PORT_ADB,
> +		.debug = true,
> +	}, {
> +		.tx_ch = PORT_CH_MIPC_TX,
> +		.rx_ch = PORT_CH_MIPC_RX,
> +		.txq_index = Q_IDX_MIPC,
> +		.rxq_index = Q_IDX_MIPC,
> +		.path_id = CLDMA_ID_MD,
> +		.ops = &wwan_sub_port_ops,
> +		.name = "mipc",
> +		.port_type = WWAN_PORT_MIPC,
> +		.debug = true,
> +	}
>   };
>   
...

>> +void t7xx_proxy_port_debug(struct t7xx_pci_dev *t7xx_dev, bool show)
>> +{
>> +	struct port_proxy *port_prox = t7xx_dev->md->port_prox;
>> +	struct t7xx_port *port;
>> +	int i;
>> +
>> +	for_each_proxy_port(i, port, port_prox) {
>> +		const struct t7xx_port_conf *port_conf = port->port_conf;
>> +
>> +		spin_lock_init(&port->port_update_lock);
>
>This lock initialization does not seems correct. Should we reinitialize 
>the lock on port hiding? And looks like the lock was already initialized 

Yes, it should't reinitalize, let me fix it.

>> +		if (port_conf->debug && port_conf->ops && port_conf->ops->init) {
>> +			if (show)
>> +				port_conf->ops->init(port);
>> +			else
>> +				port_conf->ops->uninit(port);
>
>This part is also does not seems correct. Existing of the 'init' 
>operation does not imply existing of 'uninit' operation. See 
>t7xx_port_proxy_uninit() function.
>
>Also t7xx_port_proxy_uninit() will call the uninitialization operation 
>for us. Is it safe to call the uninitialization operation twice? Once to 
>hide the ports and another one time on a driver unloading. Or what 
>happens if someone will write 'normal' into 't7xx_mode' twice?
>
>The same question is valid regarding the initialization (ports showing). 
>If someone will write 'debug' into 't7xx_mode' twice, then we will 
>register the same ADB port twice. Isn't it?

init() and uninit() has check the pointer of the port, if porinter is NULL, there
will no more operation, so it will not call then twice.

Code 'if (!port->wwan.wwan_port)' will check if the port has inited.

static void t7xx_port_wwan_create(struct t7xx_port *port)
{
	const struct t7xx_port_conf *port_conf = port->port_conf;
	unsigned int header_len = sizeof(struct ccci_header), mtu;
	struct wwan_port_caps caps;

	if (!port->wwan.wwan_port) {
		mtu = t7xx_get_port_mtu(port);
		caps.frag_len = mtu - header_len;
		caps.headroom_len = header_len;
		port->wwan.wwan_port = wwan_create_port(port->dev, port_conf->port_type,
							&wwan_ops, &caps, port);
		if (IS_ERR(port->wwan.wwan_port))
			dev_err(port->dev, "Unable to create WWAN port %s", port_conf->name);
	}
}

static int t7xx_port_wwan_init(struct t7xx_port *port)
{
	const struct t7xx_port_conf *port_conf = port->port_conf;

	if (port_conf->port_type == WWAN_PORT_FASTBOOT)
		t7xx_port_wwan_create(port);

	port->rx_length_th = RX_QUEUE_MAXLEN;
	return 0;
}

Code 'if (!port->wwan.wwan_port)' will check whether port has uninited.

static void t7xx_port_wwan_uninit(struct t7xx_port *port)
{
	if (!port->wwan.wwan_port)
		return;

	port->rx_length_th = 0;
	wwan_remove_port(port->wwan.wwan_port);
	port->wwan.wwan_port = NULL;
}


Thanks.

Jinjian,
Best Regards.

Powered by blists - more mailing lists