public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: "Ji-Ze Hong (Peter Hong)" <hpeter@gmail.com>
Cc: Johan Hovold <johan@kernel.org>,
	gregkh@linuxfoundation.org,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	tom_tsai@fintek.com.tw, peter_hong@fintek.com.tw,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Ji-Ze Hong (Peter Hong)" <hpeter+linux_kernel@gmail.com>
Subject: Re: [PATCH V9 1/1] usb:serial: Add Fintek F81532/534 driver
Date: Tue, 23 Aug 2016 11:50:56 +0200	[thread overview]
Message-ID: <20160823095056.GI16896@localhost> (raw)
In-Reply-To: <d1a32b2f-c90a-69f6-3063-f0babd2a020a@gmail.com>

On Tue, Aug 23, 2016 at 04:23:44PM +0800, Ji-Ze Hong (Peter Hong) wrote:
> Hi Johan,
> 
> Johan Hovold 於 2016/8/22 下午 09:14 寫道:

> >> +{
> >> +	size_t count = F81534_USB_MAX_RETRY;
> >> +	int status;
> >> +	u8 *tmp;
> >> +
> >> +	tmp = kmalloc(sizeof(u8), GFP_KERNEL);
> >> +	if (!tmp)
> >> +		return -ENOMEM;
> >> +
> >> +	*tmp = data;
> >> +
> >> +	/*
> >> +	 * Our device maybe not reply when heavily loading, We'll retry for
> >> +	 * F81534_USB_MAX_RETRY times.
> >> +	 */
> >> +	while (count--) {
> >> +		status = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
> >> +					 F81534_SET_GET_REGISTER,
> >> +					 USB_TYPE_VENDOR | USB_DIR_OUT,
> >> +					 reg, 0, tmp, sizeof(u8),
> >> +					 F81534_USB_TIMEOUT);
> >> +		if (status > 0)
> >> +			break;
> >> +
> >> +		if (status == 0)
> >> +			status = -EIO;
> >> +	}
> >> +
> >> +	if (status < 0) {
> >> +		dev_err(&dev->dev, "%s: reg: %x data: %x failed: %d\n",
> >> +				__func__, reg, data, status);
> >> +		kfree(tmp);
> >> +		return status;
> >
> > I'd use a common exit path to free tmp, and just print an error here.
> 
> I'll change this with next patch. BTW, Alan had suggested me to re-write
> set/get register function to avoid kmalloc(), but I found some issue
> to re-write.
> 
> We need to read the internal storage to determinate the port counts in
> f81534_calc_num_ports(), but in this moment the usb_serial had no
> private data, it still need to use kmalloc() to get memory.
> 
> The following source code is my current modification. I'll kmalloc
> the buffer if it can't get serial_private, otherwise I'll use
> serial_private buffer and protected by a mutex. Should I do something
> to improve it?

I'd say it's not worth trying to avoid that extra allocation, and there
will be several further allocations done in the usb_control_msg path
anyway. What you have today (i.e. in v9) is fine.

> >> +static int f81534_calc_num_ports(struct usb_serial *serial)
> >> +{
> >> +	unsigned char setting[F81534_CUSTOM_DATA_SIZE];
> >> +	uintptr_t setting_idx;
> >> +	u8 num_port = 0;
> >> +	int status;
> >> +	size_t i;
> >> +
> >> +	/* Check had custom setting */
> >> +	status = f81534_find_config_idx(serial, &setting_idx);
> >> +	if (status) {
> >> +		dev_err(&serial->dev->dev, "%s: find idx failed: %d\n",
> >> +				__func__, status);
> >> +		return 0;
> >> +	}
> >> +
> >> +	/* Save the configuration area idx as private data for attach() */
> >> +	usb_set_serial_data(serial, (void *)setting_idx);
> >> +
> >> +	/* Read default board setting */
> >> +	status = f81534_read_data(serial, F81534_DEF_CONF_ADDRESS_START,
> >> +				  F81534_NUM_PORT, setting);
> >> +	if (status) {
> >> +		dev_err(&serial->dev->dev, "%s: read failed: %d\n", __func__,
> >> +				status);
> >> +		return 0;
> >> +	}
> >> +
> >> +	/*
> >> +	 * If had custom setting, override it. 1st byte is a indicator, 0xff
> >> +	 * is empty, F81534_CUSTOM_VALID_TOKEN is had data, then skip with 1st
> >> +	 * data
> >> +	 */
> >> +	if (setting_idx != F81534_CUSTOM_NO_CUSTOM_DATA) {
> >> +		status = f81534_read_data(serial, F81534_CUSTOM_ADDRESS_START +
> >> +						F81534_CONF_OFFSET,
> >> +						sizeof(setting), setting);
> >> +		if (status) {
> >> +			dev_err(&serial->dev->dev,
> >> +					"%s: get custom data failed: %d\n",
> >> +					__func__, status);
> >> +			return 0;
> >> +		}
> >> +
> >> +		dev_dbg(&serial->dev->dev,
> >> +				"%s: read configure from block: %d\n",
> >> +				__func__, (unsigned int)setting_idx);
> >> +	} else {
> >> +		dev_dbg(&serial->dev->dev, "%s: read configure default\n",
> >> +				__func__);
> >> +	}
> >> +
> >> +	/* New style, find all possible ports */
> >> +	num_port = 0;
> >> +	for (i = 0; i < F81534_NUM_PORT; ++i) {
> >> +		if (setting[i] & F81534_PORT_UNAVAILABLE)
> >> +			continue;
> >
> > Looks like setting[] could be uninitialised here.
> 
> Our IC will preserve 2 section for configuration data. One is
> F81534_DEF_CONF_ADDRESS_START, another is F81534_CUSTOM_ADDRESS_START.
> 
> We'll read F81534_DEF_CONF_ADDRESS_START first for default value and
> read F81534_CUSTOM_ADDRESS_START for customer value.

My bad, I missed the first read above, sorry.

> >> +		tty_port_num = f81534_phy_to_logic_port(serial, phy_port_num);
> >> +		port = serial->port[tty_port_num];
> >> +
> >> +		/*
> >> +		 * The device will send back all information when we submitted
> >> +		 * a read URB (MSR/DATA/TX_EMPTY). But it maybe get callback
> >> +		 * before port_probe() or after port_remove().
> >> +		 *
> >> +		 * So we'll verify the pointer. If the pointer is NULL, it's
> >> +		 * mean the port not init complete and the block will skip.
> >> +		 */
> >> +		port_priv = usb_get_serial_port_data(port);
> >
> > Check if the port has been opened here instead, no need to store MSR for
> > an unused port above.
> 
> It's useless for MSR & Receive data when port is closed, but we need
> the URB to receive TX empty flag. We may not received TX empty flag
> if we don't process when port is closed. It'll make the port not
> workable.

But you explicitly clear the xmit fifo on open it seems?

Thanks,
Johan

  reply	other threads:[~2016-08-23  9:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31  1:51 [PATCH V9 1/1] usb:serial: Add Fintek F81532/534 driver Ji-Ze Hong (Peter Hong)
2016-08-22 13:14 ` Johan Hovold
2016-08-23  8:23   ` Ji-Ze Hong (Peter Hong)
2016-08-23  9:50     ` Johan Hovold [this message]
2016-08-24  6:36       ` Ji-Ze Hong (Peter Hong)

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=20160823095056.GI16896@localhost \
    --to=johan@kernel.org \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpeter+linux_kernel@gmail.com \
    --cc=hpeter@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=peter_hong@fintek.com.tw \
    --cc=tom_tsai@fintek.com.tw \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox