public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Baojun Xu <baojun.xu@ti.com>
Cc: tiwai@suse.de, robh+dt@kernel.org, lgirdwood@gmail.com,
	perex@perex.cz, pierre-louis.bossart@linux.intel.com,
	kevin-lu@ti.com, 13916275206@139.com,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	liam.r.girdwood@intel.com, yung-chuan.liao@linux.intel.com,
	broonie@kernel.org, soyer@irl.hu
Subject: Re: [PATCH v1 7/8] ALSA: hda/tas2781: Add tas2781 SPI-based driver
Date: Tue, 26 Mar 2024 17:15:03 +0200	[thread overview]
Message-ID: <ZgLmd64URUOJ0pB9@smile.fi.intel.com> (raw)
In-Reply-To: <20240326010905.2147-7-baojun.xu@ti.com>

On Tue, Mar 26, 2024 at 09:09:04AM +0800, Baojun Xu wrote:
> Firmware binary load lib code for tas2781 spi driver.

...

> +// tas2781_spi_fwlib.c -- TASDEVICE firmware support

Please, remove file names from the files. This is just a burden: in case the
file gets renamed, often people forgot to update its contents.

Same applies to all such cases.

...

> +#define ERROR_PRAM_CRCCHK			0x0000000
> +#define ERROR_YRAM_CRCCHK			0x0000001
> +#define	PPC_DRIVER_CRCCHK			0x00000200

Stray TAB after define.

...

> +	/* In most projects are many audio cases, such as music, handfree,
> +	 * receiver, games, audio-to-haptics, PMIC record, bypass mode,
> +	 * portrait, landscape, etc. Even in multiple audios, one or
> +	 * two of the chips will work for the special case, such as
> +	 * ultrasonic application. In order to support these variable-numbers
> +	 * of audio cases, flexible configs have been introduced in the
> +	 * dsp firmware.

DSP

> +	 */

/*
 * The correct style of the multi-line comments
 * outside of net subsystem is depicted here. Please,
 * follow and update all the comments accordingly.
 */

...

> +	cfg_info = kzalloc(sizeof(struct tasdevice_config_info), GFP_KERNEL);

sizeof(*cfg_info)
Same applies to all similar cases.


> +	if (!cfg_info) {
> +		*status = -ENOMEM;
> +		goto out;
> +	}

...

> +	if (tas_priv->rcabin.fw_hdr.binary_version_num >= 0x105) {
> +		if (config_offset + 64 > (int)config_size) {

Explicit casting and to signed (sic!) is prone to mistakes. Can you refactor
to get rid of the casting?

> +			*status = -EINVAL;
> +			dev_err(tas_priv->dev, "add conf: Out of boundary\n");
> +			goto out;
> +		}
> +		config_offset += 64;
> +	}

...

> +	if (config_offset + 4 > (int)config_size) {

Ditto.

> +		*status = -EINVAL;
> +		dev_err(tas_priv->dev, "add config: Out of boundary\n");
> +		goto out;
> +	}

...

> +	/* convert data[offset], data[offset + 1], data[offset + 2] and
> +	 * data[offset + 3] into host
> +	 */

See above about comment style.

...

> +	cfg_info->nblocks =
> +		be32_to_cpup((__be32 *)&config_data[config_offset]);

Castings to bitwise types is something that should not happen.
So, this looks like homegrown version of get_unaligned_be32().

...

> +	bk_da = cfg_info->blk_data = kcalloc(cfg_info->nblocks,
> +		sizeof(struct tasdev_blk_data *), GFP_KERNEL);

sizeof(*bk_da) ?

> +	if (!bk_da) {
> +		*status = -ENOMEM;
> +		goto out;
> +	}

...

> +		if (bk_da[i]->block_type == TASDEVICE_BIN_BLK_PRE_POWER_UP) {
> +			if (bk_da[i]->dev_idx == 0)
> +				cfg_info->active_dev =
> +					(1 << tas_priv->ndev) - 1;
> +			else
> +				cfg_info->active_dev |= 1 <<
> +					(bk_da[i]->dev_idx - 1);

Use BIT()

> +

Stray blank line.

> +		}

...

> +		bk_da[i]->yram_checksum =
> +			be16_to_cpup((__be16 *)&config_data[config_offset]);
> +		config_offset += 2;
> +		bk_da[i]->block_size =
> +			be32_to_cpup((__be32 *)&config_data[config_offset]);
> +		config_offset += 4;
> +
> +		bk_da[i]->n_subblks =
> +			be32_to_cpup((__be32 *)&config_data[config_offset]);

get_unaligned_beXX() in all cases, beyond and above.

...

> +out:

Useless label, return directly.

> +	return cfg_info;

This also applies to many places in the code.

...

So, I have stopped here as I believe you have already enough material to rework
the series. I believe with my comments addressed you may shrink the code base
by ~5%.

Also next version probably needs a cover letter to explain a bit
what is this for and why you split patches in the unusual way and how you
suggested to get them working in between (to pass bisectability test).

-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2024-03-26 15:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-26  1:08 [PATCH v1 1/8] ALSA: hda/tas2781: Add tas2781 SPI-based driver Baojun Xu
2024-03-26  1:08 ` [PATCH v1 2/8] " Baojun Xu
2024-03-26 15:00   ` Andy Shevchenko
2024-03-26 15:22     ` Takashi Iwai
2024-03-26  1:09 ` [PATCH v1 3/8] " Baojun Xu
2024-03-26  1:09 ` [PATCH v1 4/8] " Baojun Xu
2024-03-26 15:01   ` Andy Shevchenko
2024-03-26 15:03     ` Andy Shevchenko
2024-03-26  1:09 ` [PATCH v1 5/8] " Baojun Xu
2024-03-26  1:09 ` [PATCH v1 6/8] " Baojun Xu
2024-03-26 15:05   ` Pierre-Louis Bossart
2024-04-06  7:43     ` [EXTERNAL] " Xu, Baojun
2024-03-26  1:09 ` [PATCH v1 7/8] " Baojun Xu
2024-03-26 15:13   ` Pierre-Louis Bossart
2024-03-26 15:16     ` Andy Shevchenko
2024-03-26 15:15   ` Andy Shevchenko [this message]
2024-03-27 10:02   ` Gergo Koteles
2024-04-05 15:51     ` [EXTERNAL] " Xu, Baojun
2024-03-26  1:09 ` [PATCH v1 8/8] " Baojun Xu
2024-03-26 14:58 ` [PATCH v1 1/8] " Andy Shevchenko
2024-04-05 16:17   ` [EXTERNAL] " Xu, Baojun

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=ZgLmd64URUOJ0pB9@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=13916275206@139.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=baojun.xu@ti.com \
    --cc=broonie@kernel.org \
    --cc=kevin-lu@ti.com \
    --cc=lgirdwood@gmail.com \
    --cc=liam.r.girdwood@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=robh+dt@kernel.org \
    --cc=soyer@irl.hu \
    --cc=tiwai@suse.de \
    --cc=yung-chuan.liao@linux.intel.com \
    /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