Re: [PATCH v2 2/2] ASoC: rsnd: ssi: remove unnesessary period_pos
Hi Jiada Thank you for your feedback > >> Further more, if the passed 'byte' amount to > >> rsnd_ssi_pointer_update() is more than byte_per_period. > >> the calculation of next_period_byte isn't correct. > > Is it really happen ?? > > > > Basically, I have no objection about this patch, > > but this explanation is very strange for me... > No, I didn't see the issue, > but the implementation of rsnd_ssi_pointer_update(), behaves like > it knows all caller will always pass 'byte' no larger than byte_per_period, > without any check internally. > > I am ok to remove this explanation from commit message, > what do you think? This function is used from PIO mode only now, and "byte" is sizeof(u32) (Its size was "byte_per_period" when DMA mode used). This "Further more" case never happen. Removing from commit message is better for reader, IMO. Best regards --- Kuninori Morimoto
Re: [PATCH v2 2/2] ASoC: rsnd: ssi: remove unnesessary period_pos
Hi Jiada Thank you for your feedback > >> Further more, if the passed 'byte' amount to > >> rsnd_ssi_pointer_update() is more than byte_per_period. > >> the calculation of next_period_byte isn't correct. > > Is it really happen ?? > > > > Basically, I have no objection about this patch, > > but this explanation is very strange for me... > No, I didn't see the issue, > but the implementation of rsnd_ssi_pointer_update(), behaves like > it knows all caller will always pass 'byte' no larger than byte_per_period, > without any check internally. > > I am ok to remove this explanation from commit message, > what do you think? This function is used from PIO mode only now, and "byte" is sizeof(u32) (Its size was "byte_per_period" when DMA mode used). This "Further more" case never happen. Removing from commit message is better for reader, IMO. Best regards --- Kuninori Morimoto
Re: [PATCH v2 2/2] ASoC: rsnd: ssi: remove unnesessary period_pos
Hi Morimoto-san On 12/07/2017 01:58 AM, Kuninori Morimoto wrote: Hi Jiada Further more, if the passed 'byte' amount to rsnd_ssi_pointer_update() is more than byte_per_period. the calculation of next_period_byte isn't correct. Is it really happen ?? Basically, I have no objection about this patch, but this explanation is very strange for me... No, I didn't see the issue, but the implementation of rsnd_ssi_pointer_update(), behaves like it knows all caller will always pass 'byte' no larger than byte_per_period, without any check internally. I am ok to remove this explanation from commit message, what do you think? Thanks, Jiada Best regards --- Kuninori Morimoto
Re: [PATCH v2 2/2] ASoC: rsnd: ssi: remove unnesessary period_pos
Hi Morimoto-san On 12/07/2017 01:58 AM, Kuninori Morimoto wrote: Hi Jiada Further more, if the passed 'byte' amount to rsnd_ssi_pointer_update() is more than byte_per_period. the calculation of next_period_byte isn't correct. Is it really happen ?? Basically, I have no objection about this patch, but this explanation is very strange for me... No, I didn't see the issue, but the implementation of rsnd_ssi_pointer_update(), behaves like it knows all caller will always pass 'byte' no larger than byte_per_period, without any check internally. I am ok to remove this explanation from commit message, what do you think? Thanks, Jiada Best regards --- Kuninori Morimoto
Re: [PATCH v2 2/2] ASoC: rsnd: ssi: remove unnesessary period_pos
Hi Jiada > Further more, if the passed 'byte' amount to > rsnd_ssi_pointer_update() is more than byte_per_period. > the calculation of next_period_byte isn't correct. Is it really happen ?? Basically, I have no objection about this patch, but this explanation is very strange for me... Best regards --- Kuninori Morimoto
Re: [PATCH v2 2/2] ASoC: rsnd: ssi: remove unnesessary period_pos
Hi Jiada > Further more, if the passed 'byte' amount to > rsnd_ssi_pointer_update() is more than byte_per_period. > the calculation of next_period_byte isn't correct. Is it really happen ?? Basically, I have no objection about this patch, but this explanation is very strange for me... Best regards --- Kuninori Morimoto
