All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>
To: "Ding, Shenghao" <shenghao-ding@ti.com>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: "Lu, Kevin" <kevin-lu@ti.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Xu, Baojun" <x1077012@ti.com>, "Gupta, Peeyush" <peeyush@ti.com>,
	"Navada Kanyana, Mukund" <navada@ti.com>,
	Shenghao Ding <13916275206@139.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"pierre-louis.bossart@linux.intel.com"
	<pierre-louis.bossart@linux.intel.com>
Subject: Re: [EXTERNAL] Re: [PATCH v10] ASoC: tas2781: Add tas2781 driver
Date: Wed, 5 Apr 2023 13:35:34 +0200	[thread overview]
Message-ID: <030c2cbf-dec3-91fb-ac82-949cf5764b78@linux.intel.com> (raw)
In-Reply-To: <bbae9e35f2bf4cbcbc78f852041e4b2e@ti.com>

On 4/5/2023 1:21 PM, Ding, Shenghao wrote:
> Hi Both
> I wrote a test code to verify the be32_to_cpu & be32_to_cpup,
> static int __init lkm_init(void)
> {
> 	char test_buf[]={0x12, 0x34, 0xab, 0xbc, 0x56, 0x78, 0xef};
> 	unsigned int *k, p, q;
> 	int i;
> 
> 	printk("Hello, Shanghai!\n");
> 
> 	for (i = 0; i < 4; i ++) {
> 		k = (unsigned int *)&test_buf[i];
> 		p = be32_to_cpup((__be32 *)k);
> 		q = be32_to_cpu(test_buf[i]);
> 		printk("%d: *k = 0x%08x p = 0x%08x q = 0x%08x %ld\n",
> 			i, *k, p, q, sizeof(unsigned int));
> 	}
> 	return 0;
> }
> The output is:
> [ 9109.722548] Hello, Shanghai!
> [ 9109.726287] 0: *k = 0xbcab3412 p = 0x1234abbc q = 0x12000000 4
> [ 9109.727665] 1: *k = 0x56bcab34 p = 0x34abbc56 q = 0x34000000 4
> [ 9109.728553] 2: *k = 0x7856bcab p = 0xabbc5678 q = 0xabffffff 4
> [ 9109.729308] 3: *k = 0xef7856bc p = 0xbc5678ef q = 0xbcffffff 4
> Apparently, be32_to_cpup's output is what I expected.
> Looking forward to your comments. Thanks.
> 

It makes sense, as array access reads 8 bit value, you would need to 
access value using pointer instead. So instead of doing 
be32_to_cpu(test_buf[i]) you would need to do be32_to_cpu(*(test_buf + 
i)) if I didn't mess the pointer magic ;)

And then I'm not sure which is better, be32_to_cpup or be32_to_cpu.

> BR
> Shenghao Ding
> -----Original Message-----
> From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> Sent: Saturday, April 1, 2023 4:41 AM
> To: Ding, Shenghao <shenghao-ding@ti.com>; Amadeusz Slawinski <amadeuszx.slawinski@linux.intel.com>; Shenghao Ding <13916275206@139.com>; broonie@kernel.org; lgirdwood@gmail.com; perex@perex.cz; pierre-louis.bossart@linux.intel.com
> Cc: Lu, Kevin <kevin-lu@ti.com>; alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org; Xu, Baojun <x1077012@ti.com>; Gupta, Peeyush <peeyush@ti.com>; Navada Kanyana, Mukund <navada@ti.com>
> Subject: [EXTERNAL] Re: [PATCH v10] ASoC: tas2781: Add tas2781 driver
> 
> Le 31/03/2023 à 04:19, Ding, Shenghao a écrit :
>> Hi Amadeusz Sławiński
>> Thanks for your comment.
>> Answer inline.
>>
>> -----Original Message-----
>> From: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
>> Sent: Thursday, March 30, 2023 7:54 PM
>> To: Shenghao Ding <13916275206@139.com>; broonie@kernel.org;
>> lgirdwood@gmail.com; perex@perex.cz;
>> pierre-louis.bossart@linux.intel.com
>> Cc: Lu, Kevin <kevin-lu@ti.com>; Ding, Shenghao
>> <shenghao-ding@ti.com>; alsa-devel@alsa-project.org;
>> linux-kernel@vger.kernel.org; Xu, Baojun <x1077012@ti.com>; Gupta,
>> Peeyush <peeyush@ti.com>; Navada Kanyana, Mukund <navada@ti.com>
>> Subject: [EXTERNAL] Re: [PATCH v10] ASoC: tas2781: Add tas2781 driver
>>
>> On 3/29/2023 12:01 PM, Shenghao Ding wrote:
>>> Create tas2781 driver.
>>>
>>> Signed-off-by: Shenghao Ding <13916275206@139.com>
>>>
>>> ---
>>> Changes in v10:
>>>     - using be16_to_cpu and be32_to_cpu instead of SMS_HTONS and SMS_HTONL
>>>     - optimize and reduce the boundary checks
>>>     - Add comments on some kmemdup instead of kzalloc+memcpy
>>>     Changes to be committed:
>>> 	modified:   sound/soc/codecs/Kconfig
>>> 	modified:   sound/soc/codecs/Makefile
>>> 	new file:   sound/soc/codecs/tas2781-dsp.c
>>> 	new file:   sound/soc/codecs/tas2781-dsp.h
>>> 	new file:   sound/soc/codecs/tas2781-i2c.c
>>> 	new file:   sound/soc/codecs/tas2781.h
>>> ---
>>
>> ...
>>
>>> +
>>> +static int fw_parse_block_data_kernel(struct tasdevice_fw *tas_fmw,
>>> +	struct tasdev_blk *block, const struct firmware *fmw, int offset) {
>>> +	const unsigned char *data = fmw->data;
>>> +
>>> +	if (offset + 16 > fmw->size) {
>>> +		dev_err(tas_fmw->dev, "%s: File Size error\n", __func__);
>>> +		offset = -EINVAL;
>>> +		goto out;
>>> +	}
>>> +	block->type = be32_to_cpup((__be32 *)&data[offset]);
>>
>> Wouldn't just be32_to_cpu(data[offset]) work instead of be32_to_cpup?
>> Same in other cases.
>> [DING] data[] is a char array, the code will convert data[offset],
>> data[offset + 1], data[offset + 2] and data[offset + 3] into host instead of data[offset] only.
>>
> 
> Not sure to follow you.
> Isn't it the purpose of be32_to_cpu() to take a 32 bits word, in other words 4 x 8 bits char, and swap what if needed (little endian arch)?
> 
> It ends to __swab32() ([1] for the "constant" implementation)
> 
> 
> be32_to_cpup(&p) ends to __swab32(*p), which really looks to the same as be32_to_cpu(p).
> 
> Can you elaborate more?
> 
> CJ
> 
> 
> [1]:
> https://elixir.bootlin.com/linux/v6.3-rc3/source/include/uapi/linux/swab.h#L18
> 


WARNING: multiple messages have this Message-ID (diff)
From: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>
To: "Ding, Shenghao" <shenghao-ding@ti.com>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: "Lu, Kevin" <kevin-lu@ti.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Xu, Baojun" <x1077012@ti.com>, "Gupta, Peeyush" <peeyush@ti.com>,
	"Navada Kanyana, Mukund" <navada@ti.com>,
	Shenghao Ding <13916275206@139.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"perex@perex.cz" <perex@perex.cz>,
	"pierre-louis.bossart@linux.intel.com" 
	<pierre-louis.bossart@linux.intel.com>
Subject: Re: [EXTERNAL] Re: [PATCH v10] ASoC: tas2781: Add tas2781 driver
Date: Wed, 5 Apr 2023 13:35:34 +0200	[thread overview]
Message-ID: <030c2cbf-dec3-91fb-ac82-949cf5764b78@linux.intel.com> (raw)
In-Reply-To: <bbae9e35f2bf4cbcbc78f852041e4b2e@ti.com>

On 4/5/2023 1:21 PM, Ding, Shenghao wrote:
> Hi Both
> I wrote a test code to verify the be32_to_cpu & be32_to_cpup,
> static int __init lkm_init(void)
> {
> 	char test_buf[]={0x12, 0x34, 0xab, 0xbc, 0x56, 0x78, 0xef};
> 	unsigned int *k, p, q;
> 	int i;
> 
> 	printk("Hello, Shanghai!\n");
> 
> 	for (i = 0; i < 4; i ++) {
> 		k = (unsigned int *)&test_buf[i];
> 		p = be32_to_cpup((__be32 *)k);
> 		q = be32_to_cpu(test_buf[i]);
> 		printk("%d: *k = 0x%08x p = 0x%08x q = 0x%08x %ld\n",
> 			i, *k, p, q, sizeof(unsigned int));
> 	}
> 	return 0;
> }
> The output is:
> [ 9109.722548] Hello, Shanghai!
> [ 9109.726287] 0: *k = 0xbcab3412 p = 0x1234abbc q = 0x12000000 4
> [ 9109.727665] 1: *k = 0x56bcab34 p = 0x34abbc56 q = 0x34000000 4
> [ 9109.728553] 2: *k = 0x7856bcab p = 0xabbc5678 q = 0xabffffff 4
> [ 9109.729308] 3: *k = 0xef7856bc p = 0xbc5678ef q = 0xbcffffff 4
> Apparently, be32_to_cpup's output is what I expected.
> Looking forward to your comments. Thanks.
> 

It makes sense, as array access reads 8 bit value, you would need to 
access value using pointer instead. So instead of doing 
be32_to_cpu(test_buf[i]) you would need to do be32_to_cpu(*(test_buf + 
i)) if I didn't mess the pointer magic ;)

And then I'm not sure which is better, be32_to_cpup or be32_to_cpu.

> BR
> Shenghao Ding
> -----Original Message-----
> From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> Sent: Saturday, April 1, 2023 4:41 AM
> To: Ding, Shenghao <shenghao-ding@ti.com>; Amadeusz Slawinski <amadeuszx.slawinski@linux.intel.com>; Shenghao Ding <13916275206@139.com>; broonie@kernel.org; lgirdwood@gmail.com; perex@perex.cz; pierre-louis.bossart@linux.intel.com
> Cc: Lu, Kevin <kevin-lu@ti.com>; alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org; Xu, Baojun <x1077012@ti.com>; Gupta, Peeyush <peeyush@ti.com>; Navada Kanyana, Mukund <navada@ti.com>
> Subject: [EXTERNAL] Re: [PATCH v10] ASoC: tas2781: Add tas2781 driver
> 
> Le 31/03/2023 à 04:19, Ding, Shenghao a écrit :
>> Hi Amadeusz Sławiński
>> Thanks for your comment.
>> Answer inline.
>>
>> -----Original Message-----
>> From: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
>> Sent: Thursday, March 30, 2023 7:54 PM
>> To: Shenghao Ding <13916275206@139.com>; broonie@kernel.org;
>> lgirdwood@gmail.com; perex@perex.cz;
>> pierre-louis.bossart@linux.intel.com
>> Cc: Lu, Kevin <kevin-lu@ti.com>; Ding, Shenghao
>> <shenghao-ding@ti.com>; alsa-devel@alsa-project.org;
>> linux-kernel@vger.kernel.org; Xu, Baojun <x1077012@ti.com>; Gupta,
>> Peeyush <peeyush@ti.com>; Navada Kanyana, Mukund <navada@ti.com>
>> Subject: [EXTERNAL] Re: [PATCH v10] ASoC: tas2781: Add tas2781 driver
>>
>> On 3/29/2023 12:01 PM, Shenghao Ding wrote:
>>> Create tas2781 driver.
>>>
>>> Signed-off-by: Shenghao Ding <13916275206@139.com>
>>>
>>> ---
>>> Changes in v10:
>>>     - using be16_to_cpu and be32_to_cpu instead of SMS_HTONS and SMS_HTONL
>>>     - optimize and reduce the boundary checks
>>>     - Add comments on some kmemdup instead of kzalloc+memcpy
>>>     Changes to be committed:
>>> 	modified:   sound/soc/codecs/Kconfig
>>> 	modified:   sound/soc/codecs/Makefile
>>> 	new file:   sound/soc/codecs/tas2781-dsp.c
>>> 	new file:   sound/soc/codecs/tas2781-dsp.h
>>> 	new file:   sound/soc/codecs/tas2781-i2c.c
>>> 	new file:   sound/soc/codecs/tas2781.h
>>> ---
>>
>> ...
>>
>>> +
>>> +static int fw_parse_block_data_kernel(struct tasdevice_fw *tas_fmw,
>>> +	struct tasdev_blk *block, const struct firmware *fmw, int offset) {
>>> +	const unsigned char *data = fmw->data;
>>> +
>>> +	if (offset + 16 > fmw->size) {
>>> +		dev_err(tas_fmw->dev, "%s: File Size error\n", __func__);
>>> +		offset = -EINVAL;
>>> +		goto out;
>>> +	}
>>> +	block->type = be32_to_cpup((__be32 *)&data[offset]);
>>
>> Wouldn't just be32_to_cpu(data[offset]) work instead of be32_to_cpup?
>> Same in other cases.
>> [DING] data[] is a char array, the code will convert data[offset],
>> data[offset + 1], data[offset + 2] and data[offset + 3] into host instead of data[offset] only.
>>
> 
> Not sure to follow you.
> Isn't it the purpose of be32_to_cpu() to take a 32 bits word, in other words 4 x 8 bits char, and swap what if needed (little endian arch)?
> 
> It ends to __swab32() ([1] for the "constant" implementation)
> 
> 
> be32_to_cpup(&p) ends to __swab32(*p), which really looks to the same as be32_to_cpu(p).
> 
> Can you elaborate more?
> 
> CJ
> 
> 
> [1]:
> https://elixir.bootlin.com/linux/v6.3-rc3/source/include/uapi/linux/swab.h#L18
> 


  reply	other threads:[~2023-04-05 11:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29 10:01 [PATCH v10] ASoC: tas2781: Add tas2781 driver Shenghao Ding
2023-03-30 11:53 ` Amadeusz Sławiński
2023-03-31  2:19   ` [EXTERNAL] " Ding, Shenghao
2023-03-31 20:41     ` Christophe JAILLET
2023-04-05 11:21       ` [EXTERNAL] " Ding, Shenghao
2023-04-05 11:35         ` Amadeusz Sławiński [this message]
2023-04-05 11:35           ` Amadeusz Sławiński
2023-04-05 12:02           ` Mark Brown
2023-04-05 12:02             ` Mark Brown
2023-04-06 18:35         ` Christophe JAILLET
2023-04-06 18:35           ` Christophe JAILLET
2023-04-05 11:21       ` Ding, Shenghao via Alsa-devel
2023-03-31  2:19   ` Ding, Shenghao via Alsa-devel
2023-03-30 18:17 ` Christophe JAILLET

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=030c2cbf-dec3-91fb-ac82-949cf5764b78@linux.intel.com \
    --to=amadeuszx.slawinski@linux.intel.com \
    --cc=13916275206@139.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=kevin-lu@ti.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=navada@ti.com \
    --cc=peeyush@ti.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=shenghao-ding@ti.com \
    --cc=x1077012@ti.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 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.