24.01.2020 06:27, Sameer Pujar пишет:
>
>
> On 1/24/2020 6:58 AM, Dmitry Osipenko wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> 20.01.2020 17:23, Sameer Pujar пишет:
>> [snip]
>>> +static bool tegra_admaif_wr_reg(struct device *dev, unsigned int reg)
>>> +{
>>> + struct tegra_admaif *admaif = dev_get_drvdata(dev);
>>> + unsigned int ch_stride = TEGRA_ADMAIF_CHANNEL_REG_STRIDE;
>>> + unsigned int num_ch = admaif->soc_data->num_ch;
>>> + unsigned int rx_base = admaif->soc_data->rx_base;
>>> + unsigned int tx_base = admaif->soc_data->tx_base;
>>> + unsigned int global_base = admaif->soc_data->global_base;
>>> + unsigned int reg_max =
>>> admaif->soc_data->regmap_conf->max_register;
>>> + unsigned int rx_max = rx_base + (num_ch * ch_stride);
>>> + unsigned int tx_max = tx_base + (num_ch * ch_stride);
>>> +
>>> + if ((reg >= rx_base) && (reg < rx_max)) {
>> The braces are not needed around the comparisons because they precede
>> the AND. Same for all other similar occurrences in the code.
>
> While that is true, some prefer to use explicit braces to make it more
> readable.
> In the past I was told to use explicitly in such cases.
At least most of code in kernel (I've seen) doesn't have superfluous
parens (the curvy thingies actually should be the braces). Readability
is arguable in this case, I'm finding such code a bit more difficult to
read, although in some cases parens and spacing may help to read more
complex constructions.
On 1/24/2020 9:55 AM, Dmitry Osipenko wrote:
> External email: Use caution opening links or attachments
>
>
> 24.01.2020 06:27, Sameer Pujar пишет:
>>
>> On 1/24/2020 6:58 AM, Dmitry Osipenko wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> 20.01.2020 17:23, Sameer Pujar пишет:
>>> [snip]
>>>> +static bool tegra_admaif_wr_reg(struct device *dev, unsigned int reg)
>>>> +{
>>>> + struct tegra_admaif *admaif = dev_get_drvdata(dev);
>>>> + unsigned int ch_stride = TEGRA_ADMAIF_CHANNEL_REG_STRIDE;
>>>> + unsigned int num_ch = admaif->soc_data->num_ch;
>>>> + unsigned int rx_base = admaif->soc_data->rx_base;
>>>> + unsigned int tx_base = admaif->soc_data->tx_base;
>>>> + unsigned int global_base = admaif->soc_data->global_base;
>>>> + unsigned int reg_max =
>>>> admaif->soc_data->regmap_conf->max_register;
>>>> + unsigned int rx_max = rx_base + (num_ch * ch_stride);
>>>> + unsigned int tx_max = tx_base + (num_ch * ch_stride);
>>>> +
>>>> + if ((reg >= rx_base) && (reg < rx_max)) {
>>> The braces are not needed around the comparisons because they precede
>>> the AND. Same for all other similar occurrences in the code.
>> While that is true, some prefer to use explicit braces to make it more
>> readable.
>> In the past I was told to use explicitly in such cases.
> At least most of code in kernel (I've seen) doesn't have superfluous
> parens (the curvy thingies actually should be the braces). Readability
> is arguable in this case, I'm finding such code a bit more difficult to
> read, although in some cases parens and spacing may help to read more
> complex constructions.
Yes this is subjective and depends on the individual reading the code. It is
confusing every time, for the sender, about which guideline to follow.
Resending
the patch/series for only this reason may not be really necessary. Since
I need
to fix couple of issues in this series I may consider removing the
explicit braces.